有一种与 Microsoft 相关的奇特现象，称为Microsoft Echo Chamber。Microsoft 是一个庞大的组织，而周围的 Microsoft 认证合作伙伴生态系统使该组织的规模成倍增长。如果你充分融入这个生态系统，就很难超越它的界限。每当您寻找 Microsoft 产品或技术问题的解决方案时，您很可能会找到涉及向其投入更多 Microsoft 产品的答案。无论您在回声室中大喊大叫，答案都是微软！

There’s a peculiar phenomenon related to Microsoft called the Microsoft Echo Chamber. Microsoft is a huge organization, and the surrounding ecosystem of Microsoft Certified Partners multiplies that size by orders of magnitude. If you’re sufficiently embedded in this ecosystem, it can be hard to see past its boundaries. Whenever you look for a solution to a problem with a Microsoft product or technology, you’re likely to find an answer that involves throwing even more Microsoft products at it. No matter what you yell within the echo chamber, the answer is Microsoft!

当 Microsoft 于 2003 年聘用我（马克）时，我已经牢牢地融入了回声室，为 Microsoft 认证合作伙伴工作了多年——我喜欢它！他们很快将我送往新奥尔良的内部技术会议，了解最新最好的 Microsoft 技术。

When Microsoft hired me (Mark) in 2003, I was already firmly embedded in the echo chamber, having worked for Microsoft Certified Partners for years—and I loved it! They soon shipped me off to an internal tech conference in New Orleans to learn about the latest and greatest Microsoft technology.

今天，我不记得我参加过的任何 Microsoft 产品会议，但我记得最后一天。那天，由于未能体验任何可以满足我对酷技术的渴望的课程，我主要是期待飞回丹麦的家。我的首要任务是找个地方坐下，这样我就可以处理我的电子邮件了，所以我选择了一个似乎与我无关的会议并启动了我的笔记本电脑。

Today, I can’t recall any of the Microsoft product sessions I attended—but I do remember the last day. On that day, having failed to experience any sessions that could satisfy my hunger for cool tech, I was mostly looking forward to flying home to Denmark. My top priority was to find a place to sit so I could attend to my email, so I chose a session that seemed marginally relevant for me and fired up my laptop.

会议结构松散，有几位主持人。其中一个是名叫 Martin Fowler 的大胡子，他谈到了测试驱动开发 (TDD) 和动态模拟。我从没听说过他，也没有仔细听，但我心里一定有什么印象。

The session was loosely structured and featured several presenters. One was a bearded guy named Martin Fowler, who talked about Test-Driven Development (TDD) and dynamic mocks. I had never heard of him, and I didn’t listen very closely, but something must have stuck in my mind.

回到丹麦后不久，我的任务是从头开始重写一个大型 ETL（提取、转换、加载）系统，我决定尝试一下 TDD（事实证明这是一个非常好的决定）。自然而然地使用了动态模拟，但也引入了管理依赖项的需要。我发现这是一个非常困难但又非常迷人的问题，我无法停止思考它。

Soon after returning to Denmark, I was tasked with rewriting a big ETL (extract, transform, load) system from scratch, and I decided to give TDD a try (it turned out to be a very good decision). The use of dynamic mocks followed naturally, but also introduced the need to manage dependencies. I found that to be a very difficult but very captivating problem, and I couldn’t stop thinking about it.

最初是我对 TDD 感兴趣的副作用，后来变成了一种热情。我做了很多研究，阅读了很多关于此事的博客文章，自己写了很多博客，试验了代码，并与任何愿意倾听的人讨论了这个话题。我越来越不得不在 Microsoft Echo Chamber 之外寻找灵感和指导。一路走来，人们将我与 ALT.NET 运动联系在一起，尽管我从来没有积极参与其中。我犯了所有可能犯的错误，但我逐渐能够对依赖注入 (DI) 形成连贯的理解。

What started as a side effect of my interest in TDD became a passion in itself. I did a lot of research, read lots of blog posts about the matter, wrote quite a few blogs myself, experimented with code, and discussed the topic with anyone who cared to listen. Increasingly, I had to look outside the Microsoft Echo Chamber for inspiration and guidance. Along the way, people associated me with the ALT.NET movement even though I was never very active in it. I made all the mistakes it was possible to make, but I was gradually able to develop a coherent understanding of Dependency Injection (DI).

当 Manning 向我提出关于 .NET 中的依赖注入的书的想法时，我的第一反应是，“这有必要吗？” 我觉得开发人员理解 DI 所需的所有概念已经在许多博客文章中进行了描述。有什么要补充的吗？老实说，我认为 .NET 中的 DI 是一个已经死了的主题。

When Manning approached me with the idea for a book about Dependency Injection in .NET, my first reaction was, “Is this even necessary?” I felt that all the concepts a developer needs to understand DI were already described in numerous blog posts. Was there anything to add? Honestly, I thought DI in .NET was a topic that had been done to death already.

然而，经过深思熟虑，我突然意识到，虽然知识肯定是存在的，但它非常分散并且使用了很多相互矛盾的术语。在本书第一版之前，没有关于 DI 的书名试图对它进行连贯的描述。进一步思考后，我意识到 Manning 为我提供了一个巨大的挑战和一个很好的机会来收集和系统化我对 DI 的所有了解。

Upon reflection, however, it dawned on me that while the knowledge is definitely out there, it’s very scattered and uses a lot of conflicting terminology. Before the first edition of this book, there were no titles about DI that attempted to present a coherent description of it. After thinking about it further, I realized that Manning was offering me a tremendous challenge and a great opportunity to collect and systematize all that I knew about DI.

结果就是这本书及其前身——第一版。它使用 .NET Core 和 C# 来介绍和描述 DI 的全面术语和指南，但我希望本书的价值能够超越平台。我认为这里阐述的模式语言是通用的。无论您是 .NET 开发人员还是使用其他面向对象的平台，我希望本书能帮助您成为更好的软件工程师。

The result is this book and its predecessor—the first edition. It uses .NET Core and C# to introduce and describe a comprehensive terminology and guidance for DI, but I hope the value of this book will reach well beyond the platform. I think the pattern language articulated here is universal. Whether you’re a .NET developer or use another object-oriented platform, I hope this book will help you be a better software engineer.

感恩似乎是陈词滥调，但这只是因为它是人性的基本组成部分。在我们写这本书的过程中，许多人给了我们很好的感激理由，我们要感谢他们所有人。

Gratitude may seem like a cliché, but this is only because it’s such a fundamental part of human nature. While we were writing the book, many people gave us good reasons to be grateful, and we would like to thank them all.

首先，在业余时间写一本书让我们对这样的项目对婚姻和家庭生活的负担有多大有了新的认识。Mark的妻子Cecilie全程陪在身边，积极支持他。最重要的是，她明白这个项目对他来说有多重要。他们还在一起，马克期待能有更多时间陪伴她和他们的孩子 Linea 和 Jarl。史蒂文的妻子朱迪思给了他完成这项艰巨任务所需的空间，但她当然很高兴这个项目终于完成了。

First of all, writing a book in our spare time has given us a new understanding of just how taxing such a project is on marriage and family life. Mark’s wife Cecilie stayed with him and actively supported him during the whole process. Most significantly, she understood just how important this project was to him. They’re still together, and Mark looks forward to being able to spend more time with her and their kids Linea and Jarl. Steven’s wife Judith gave him the space needed to complete this immense undertaking, but she certainly is glad that the project is finally finished.

在更专业的层面上，我们要感谢曼宁给我们这个机会。Michael Stephens 发起了这个项目。Dan Maharry、Marina Michaels 和 Christina Taylor 担任我们的开发编辑，并密切关注文本的质量。他们帮助我们找出手稿中的弱点，并提供了广泛的建设性批评。

On a more professional level, we want to thank Manning for giving us this opportunity. Michael Stephens initiated the project. Dan Maharry, Marina Michaels, and Christina Taylor served as our development editors and kept a keen eye on the quality of the text. They helped us identify weak spots in the manuscript and provided extensive constructive criticism.

Karsten Strøbæk 担任我们的技术开发编辑，通读了许多早期草稿，并提供了很多有用的反馈。Mark 撰写第一版时 Karsten 就在场，并在当时担任制作期间的技术校对员。在这一版中，技术校对由 Chris Heneghan 完成，他在整个手稿中发现了许多细微的错误和不一致之处。

Karsten Strøbæk served as our technical development editor, read through numerous early drafts, and provided much helpful feedback. Karsten was there when Mark wrote the first edition and served as the technical proofreader during production at that time. In this edition, technical proofreading was done by Chris Heneghan, who caught many subtle bugs and inconsistencies throughout the manuscript.

写完稿子，我们就进入了制作环节。这是由 Anthony Calcara 管理的。在此过程中，Frances Buran 是我们的文字编辑，而 Nichole Beard 则密切关注本书的图形和图表。

After we were done writing the manuscript, we entered the production process. This was managed by Anthony Calcara. During that process, Frances Buran was our copyeditor, while Nichole Beard held a close watch on the book’s graphics and diagrams.

以下审稿人在不同的发展阶段阅读了手稿，我们感谢他们的评论和见解：Ajay Bhosale、Björn Nordblom、Cemre Mengu、Dennis Sellinger、Emanuele Origgi、Ernesto Cardenas Cangahuala、Gustavo Gomes、Igor Kochetov、Jeremy Caney 、贾斯汀·库尔斯顿、米克尔·阿伦托夫特、帕斯夸莱·齐尔波利、罗伯特·莫里森、塞尔吉奥·罗梅罗、肖恩·林和斯蒂芬·伯恩。本书的评论编辑 Ivan Martinovic 使评论成为可能。

The following reviewers read the manuscript at various stages of development, and we’re grateful for their comments and insight: Ajay Bhosale, Björn Nordblom, Cemre Mengu, Dennis Sellinger, Emanuele Origgi, Ernesto Cardenas Cangahuala, Gustavo Gomes, Igor Kochetov, Jeremy Caney, Justin Coulston, Mikkel Arentoft, Pasquale Zirpoli, Robert Morrison, Sergio Romero, Shawn Lam, and Stephen Byrne. Reviewing was made possible by Ivan Martinovic, the book’s review editor.

Manning 早期访问计划 (MEAP) 的许多参与者也提供了反馈并提出了暴露文本薄弱部分的难题。

Many of the participants in the Manning Early Access Program (MEAP) also provided feedback and asked difficult questions that exposed the weak parts of the text.

特别感谢 Jeremy Caney，他最初是 MEAP 参与者，后来被提升为审稿人。他为我们提供了大量的反馈，包括语言和上下文。他对 DI 和软件设计的深刻理解非常宝贵。

Special thanks go out to Jeremy Caney, who started out as a MEAP participant but was promoted to reviewer. He supplied us with an immense amount of feedback, both linguistic and contextual. His deep understanding of DI and software design was invaluable.

还要特别感谢 Ric Slappendel。Ric 建议我们如何使用 DI 编写 UWP 应用程序。他对 WPF、UWP 和 XAML 的了解为我们节省了无数的时间和不眠之夜，并完整地塑造了 7.2 节及其配套代码示例。如果没有 Ric 的帮助，我们很可能会写出一本根本不讨论 UWP 的书。

Also special thanks to Ric Slappendel. Ric advised us on how to compose UWP applications using DI. His knowledge about WPF, UWP, and XAML saved us countless hours and sleepless nights, and completely shaped section 7.2 and its companion code examples. Without Ric’s help, we likely would’ve ended up with a book that didn’t discuss UWP at all.

Alex Meyer-Gleaves 和 Travis Illig 审阅了第 13 章的早期版本，并向我们提供了有关使用新的 Autofac 配置和 Decorator 支持的反馈。我们感谢他们的参与。

Alex Meyer-Gleaves and Travis Illig reviewed early versions of chapter 13 and provided us with feedback on using the new Autofac configuration and Decorator support. We’re grateful for their participation.

最后，Mogens Heller Grabe 礼貌地允许我们使用他的吹风机图片，直接连接到墙上的插座。

And finally, Mogens Heller Grabe courteously allowed us to use his picture of a hair dryer wired directly into a wall outlet.

这是一本关于依赖注入（DI）的书，首先也是最重要的。它也是一本关于 .NET 的书，但它的重要性要小得多。尽管 C# 用于代码示例，但本书中的大部分讨论都可以轻松应用于其他语言和平台。事实上，我们通过阅读以 Java 或 C++ 为例的书籍，了解了很多底层原理和模式。

This is a book about Dependency Injection (DI), first and foremost. It’s also a book about .NET, but that’s much less important. Although C# is used for code examples, much of the discussion in this book can be easily applied to other languages and platforms. In fact, we learned a lot of the underlying principles and patterns from reading books where Java or C++ was used in examples.

DI 是一组相关的模式和原则。它是一种思考和设计代码的方式，而不仅仅是一种特定的技术。使用 DI 的最终目的是在面向对象的范例中创建可维护的软件。

DI is a set of related patterns and principles. It’s a way to think about and design code, more than it is a specific technology. The ultimate purpose of using DI is to create maintainable software within the object-oriented paradigm.

本书中使用的概念都与面向对象编程有关。DI 解决的问题（代码可维护性）是普遍的，但建议的解决方案是在静态类型语言的面向对象编程范围内给出的：C#、Java、Visual Basic .NET、C++ 等。您不能将 DI 应用于过程编程，它可能不是函数式或动态语言中的最佳解决方案。

The concepts used throughout this book all relate to object-oriented programming. The problem that DI addresses (code maintainability) is universal, but the proposed solution is given within the scope of object-oriented programming in statically typed languages: C#, Java, Visual Basic .NET, C++, and so on. You can’t apply DI to procedural programming, and it may not be the best solution in functional or dynamic languages.

孤立的 DI 只是一件小事，但它与面向对象软件设计的大量复杂原则和模式紧密交织在一起。尽管本书自始至终始终专注于 DI，但它还根据 DI 可以提供的特定视角讨论了许多其他主题。本书的目标不仅仅是教您有关 DI 的细节：目标是让您成为更好的面向对象的程序员。

DI in isolation is just a small thing, but it’s closely interwoven with a large complex of principles and patterns for object-oriented software design. Whereas the book focuses consistently on DI from start to finish, it also discusses many of these other topics in the light of the specific perspective that DI can give. The goal of the book is more than just teaching you about DI specifics: the goal is to make you a better object-oriented programmer.

谁应该读这本书？

Who should read this book?

人们很想说这是一本面向所有 .NET 开发人员的书。但今天的 .NET 社区非常庞大，涵盖了使用 Web 应用程序、桌面应用程序、智能手机、RIA、集成、办公自动化、内容管理系统甚至游戏的开发人员。尽管 .NET 是面向对象的，但并非所有开发人员都编写面向对象的代码。

It would be tempting to state that this is a book for all .NET developers. But the .NET community today is vast and spans developers working with web applications, desktop applications, smartphones, RIA, integration, office automation, content management systems, and even games. Although .NET is object oriented, not all of those developers write object-oriented code.

这是一本关于面向对象编程的书，因此读者至少应该对面向对象感兴趣并了解什么是接口。几年的设计模式或SOLID原则的专业经验和知识当然也会大有裨益。事实上，我们并不期望初学者能从本书中学到很多东西；它主要针对有经验的开发人员和软件架构师。

This is a book about object-oriented programming, so at a minimum readers should be interested in object orientation and understand what an interface is. A few years of professional experience and knowledge of design patterns or SOLID principles will certainly be of benefit as well. In fact, we don’t expect beginners to get much out of the book; it’s mostly targeted toward experienced developers and software architects.

这些示例都是用 C# 编写的，因此使用其他 .NET 语言的读者必须能够阅读和理解 C#。熟悉 Java 和 C++ 等非 .NET 面向对象语言的读者也可能会发现这本书很有价值，因为特定于 .NET 平台的内容相对较少。就个人而言，我们阅读了很多带有 Java 示例的模式书籍，仍然从中获益良多，所以我们希望反之亦然。

The examples are all written in C#, so readers working with other .NET languages must be able to read and understand C#. Readers familiar with non-.NET object-oriented languages like Java and C++ may also find the book valuable, because the .NET platform-specific content is relatively light. Personally, we read a lot of pattern books with examples in Java and still get a lot out of them, so we hope the converse is true as well.

路线图

Roadmap

本书内容分为四个部分。理想情况下，我们希望您首先从头到尾阅读它，然后将其用作参考，但我们理解您是否有其他优先事项。出于这个原因，编写了大部分章节，以便您可以直接深入并从这一点开始阅读。

The contents of this book are divided into four parts. Ideally, we’d like you to first read it from cover to cover and then subsequently use it as a reference, but we understand if you have other priorities. For that reason, a majority of the chapters are written so that you can dive right in and start reading from that point.

第一部分是主要例外。它包含对 DI 的一般介绍，最好按顺序阅读。第二部分是模式等的目录，而第三部分也是最大的部分是从三个不同角度检查 DI。本书的第四部分是三个DI Container库的目录。

The first part is the major exception. It contains a general introduction to DI and is probably best read sequentially. The second part is a catalog of patterns and the like, whereas the third and largest part is an examination of DI from three different angles. The fourth part of the book is a catalog of three DI Container libraries.

有很多相互关联的概念，因为我们第一次介绍它们时感觉很自然，这意味着我们经常在正式介绍概念之前就提及它们。为了将这些通用概念与更多本地术语区分开来，我们始终使用小型大写字母来使它们脱颖而出。所有这些术语都在词汇表中进行了简要定义，其中还包含对更广泛描述的引用。

There are a lot of interconnected concepts, and, because we introduce them the first time it feels natural, this means we often mention concepts before we’ve formally introduced them. To distinguish these universal concepts from more local terms, we consistently use Small Caps to make them stand out. All these terms are briefly defined in the glossary, which also contains references to a more extensive description.

第 1 部分是对 DI 的一般介绍。如果您不知道什么是 DI，请从这里开始；但即使你这样做了，你也可能想要熟悉第 1 部分的内容，因为它建立了本书其余部分使用的大量上下文和术语。第 1 章讨论了 DI 的目的和好处，并提供了一个大纲。第 2 章包含一个大型且相当全面的紧耦合代码示例，第 3 章解释了如何使用 DI 重新实现相同的示例。与其他部分相比，第 1 部分的内容更为线性。您需要从头开始阅读每一章，以便从中获得最大收益。

Part 1 is a general introduction to DI. If you don’t know what DI is, this is the place to start; but even if you do, you may want to familiarize yourself with the contents of part 1, as it establishes a lot of the context and terminology used in the rest of the book. Chapter 1 discusses the purpose and benefits of DI and provides a general outline. Chapter 2 contains a big and rather comprehensive example of tightly coupled code, and chapter 3 explains how to reimplement the same example using DI. Compared to the other parts, part 1 has a more linear progression of its content. You’ll need to read each chapter from the beginning to gain the most from it.

第 2 部分是模式、反模式和代码味道的目录。在这里您可以找到关于如何实施 DI 和需要注意的危险的规范性指导。第 4 章是 DI 设计模式目录，相反，第 5 章是反模式目录。第 6 章包含常见问题的通用解决方案。作为一个目录，每一章都包含一组松散相关的部分，这些部分旨在单独阅读以及按顺序阅读。

Part 2 is a catalog of patterns, anti-patterns, and code smells. This is where you’ll find prescriptive guidance on how to implement DI and the dangers to look out for. Chapter 4 is a catalog of DI design patterns, and, conversely, chapter 5 is a catalog of anti-patterns. Chapter 6 contains generalized solutions to commonly occurring issues. As a catalog, each chapter contains a set of loosely related sections that are designed to be read in isolation as well as in sequence.

第 3 部分从三个不同的角度检查 DI：对象组合、生命周期管理和拦截。在第 7 章中，我们讨论了如何在现有应用程序框架（ASP.NET Core 和 UWP）之上实现 DI，以及如何使用控制台应用程序实现 DI。第 8 章描述了如何管理依赖生命周期以避免资源泄漏。虽然结构上没有前几章那么严格，但该章的大部分内容都可以作为知名生活方式的目录。其余三章描述了如何使用Cross-Cutting Concerns组合应用程序。第 9 章介绍拦截的基础知识使用装饰器，而第 10 章和第 11 章深入探讨了面向方面编程的概念。这是您从之前的所有工作中获益的地方，因此，在许多方面，我们认为这是本书的高潮。

Part 3 examines DI from three different angles: Object Composition, Lifetime Management, and Interception. In chapter 7, we discuss how to implement DI on top of existing application frameworks—ASP.NET Core and UWP—and how to implement DI using a console application. Chapter 8 describes how to manage Dependency lifetimes to avoid resources leaks. Whereas the structure is a little less stringent than previous chapters, a large part of that chapter can be used as a catalog of well-known Lifestyles. The remaining three chapters describe how to compose applications with Cross-Cutting Concerns. Chapter 9 goes into the basics of Interception using Decorators, whereas chapters 10 and 11 dive deep into the concept of Aspect-Oriented Programming. This is where you harvest the benefits of all the work that came before, so, in many ways, we consider this to be the climax of the book.

第 4 部分是DI 容器库的目录。它首先讨论什么是DI 容器以及它们如何融入整体情况。其余三章分别详细介绍了一个特定的容器：Autofac、Simple Injector 和 Microsoft.Extensions.DependencyInjection。为了节省空间，每一章都以相当浓缩的形式介绍其容器，因此您可能只想阅读您最感兴趣的一两个容器。在许多方面，我们将这三章视为一组非常庞大的附录。

Part 4 is a catalog of DI Container libraries. It starts with a discussion on what DI Containers are and how they fit into the overall picture. The remaining three chapters each cover a specific container in a fair amount of detail: Autofac, Simple Injector, and Microsoft.Extensions.DependencyInjection. Each chapter covers its container in a rather condensed form to save space, so you may want to read about only the one or two containers that interest you the most. In many ways, we regard these three chapters as a very big set of appendixes.

为了使 DI 原则和模式的讨论不涉及任何特定的容器 API，本书的大部分内容（第 4 部分除外）都没有引用特定的容器。这也是容器在第 4 部分中以如此强大的力量出现的原因。我们希望通过保持一般性的讨论，本书将在更长的时间内有用。

To keep the discussion of DI principles and patterns free of any specific container APIs, most of the book, with the exception of part 4, is written without referencing a particular container. This is also why the containers appear with such force in part 4. It’s our hope that by keeping the discussion general, the book will be useful for a longer period of time.

您还可以获取第 1 部分到第 3 部分中的概念，并将它们应用到第 4 部分中未涵盖的容器库。不幸的是，我们无法涵盖一些可用的好容器。但即使对于这些库的用户，我们也希望本书能提供很多帮助。

You can also take the concepts from parts 1 through 3 and apply them to container libraries not covered in part 4. There are good containers available that, unfortunately, we couldn’t cover. But even for users of these libraries, we hope that this book has a lot to offer.

代码约定和下载

Code conventions and downloads

本书中有很多代码示例。其中大部分使用 C#，但也有一些 XML 和 JSON。列表和文本中的源代码与 fixed-width font like this普通文本分开。

There are many code examples in this book. Most of those are in C#, but there’s also a bit of XML and JSON here and there. Source code in listings and text is in a fixed-width font like this to separate it from ordinary text.

本书的所有源代码均使用 C# 和 Visual Studio 2017 编写。ASP.NET Core 应用程序是针对 ASP.NET Core v2.1 编写的。

All the source code for the book is written in C# and Visual Studio 2017. The ASP.NET Core applications are written against ASP.NET Core v2.1.

本书中描述的技术中只有少数依赖于现代语言的特性。我们希望在保守和现代编码风格之间取得合理的平衡。当我们专业地编写代码时，我们会在更大程度上使用现代语言功能，但在大多数情况下，最高级的功能是泛型和 LINQ。我们最不想让你明白 DI 只能应用于超现代语言。

Only a few of the techniques described in this book hinge on modern language features. We wanted to strike a reasonable balance between conservative and modern coding styles. When we write code professionally, we use modern language features to a far greater degree, but, for the most part, the most advanced features are generics and LINQ. The last thing we want is for you to get the idea that DI can only be applied with ultra-modern languages.

为一本书编写代码示例会带来一系列挑战。与现代计算机显示器相比，一本书只允许非常短的代码行。用简短但隐晦的方法和变量名称编写简洁风格的代码是非常诱人的。即使您附近有 IDE 和调试器，这样的代码也已经很难理解为真正的代码，但在书本中很难理解。我们发现尽可能保持名称的可读性非常重要。为了使一切都合适，我们有时不得不求助于一些非正统的换行符。所有代码都可以编译，但有时格式看起来有点滑稽。

Writing code examples for a book presents its own set of challenges. Compared to a modern computer monitor, a book only allows for very short lines of code. It was very tempting to write code in a terse style with short but cryptic names for methods and variables. Such code is already difficult to understand as real code even when you have an IDE and a debugger nearby, but it becomes really difficult to follow in a book. We found it very important to keep names as readable as possible. To make it all fit, we’ve sometimes had to resort to some unorthodox line breaks. All the code compiles, but sometimes the formatting looks a bit funny.

该代码还使用了 C#var关键字。在我们的专业代码中，线宽不受书页大小的限制，我们在应用时经常使用不同的编码风格var。在这里，为了节省空间，我们var在判断显式声明使代码可读性降低时使用 whenever。

The code also makes use of the C# var keyword. In our professional code, where line width isn’t limited by the size of a book’s page, we often use a different coding style when applying var. Here, to save space, we use var whenever we judge that an explicit declaration makes the code less readable.

类这个词通常用作类型的同义词。在.NET中，类、结构、接口、枚举等都是类型，但由于类型这个词在普通语言中也是一个含义重载很多的词，如果使用它往往会使文本不太清晰。

The word class is often used as a synonym for a type. In .NET, classes, structs, interfaces, enums, and so on are all types, but because the word type is also a word with a lot of overloaded meaning in ordinary language, it would often make the text less clear if used.

本书中的大部分代码都与贯穿全书的一个总体示例相关：一个带有支持性内部管理应用程序的在线商店。这是您可以在任何软件文本中看到的最不令人兴奋的示例，但我们选择它有以下几个原因：

Most of the code in this book relates to an overarching example running through the book: an online store complete with supporting internal management applications. This is about the least exciting example you can expect to see in any software text, but we chose it for a few reasons:

• 对于大多数读者来说，这是一个众所周知的问题领域。虽然这看起来很无聊，但我们认为这是一个优势，因为它不会从 DI 中抢走焦点。
• It’s a well-known problem domain for most readers. Although it may seem boring, we think this is an advantage, because it doesn’t steal focus from DI.
• 我们还必须承认，我们真的想不出任何其他领域足以支持我们想到的所有不同场景。
• We also have to admit that we couldn’t really think of any other domain that was rich enough to support all the different scenarios we had in mind.

我们编写了大量代码来支持代码示例，其中大部分代码不在本书中。事实上，我们几乎使用测试驱动开发 (TDD) 编写了所有内容，但由于这不是一本 TDD 书籍，因此我们通常不会在书中展示单元测试。

We wrote a lot of code to support the code examples, and most of that code isn’t in this book. In fact, we wrote almost all of it using Test-Driven Development (TDD), but as this isn’t a TDD book, we generally don’t show the unit tests in the book.

本书中所有示例的源代码都可以从 Manning 的网站获得：www.manning.com/books/dependency-injection-principles-practices-patterns。下载根目录中的 README.md 包含编译和运行代码的说明。

The source code for all examples in this book is available from Manning’s website: www.manning.com/books/dependency-injection-principles-practices-patterns. The README.md in the root of the download contains instructions for compiling and running the code.

liveBook 论坛

liveBook discussion forum

购买依赖注入原则、实践和模式，包括免费访问由 Manning Publications 运营的私人网络论坛，您可以在其中对本书发表评论、提出技术问题，并从作者和其他用户那里获得帮助。要访问论坛并订阅它，请将 Web 浏览器指向https://livebook.manning.com/#!/book/dependency-injection-principles-practices-patterns/discussion。您还可以在https://livebook.manning.com/#!/discussion上了解有关 Manning 论坛和行为规则的更多信息。

The purchase of Dependency Injection Principles, Practices, and Patterns, includes free access to a private web forum run by Manning Publications, where you can make comments about the book, ask technical questions, and receive help from the authors and from other users. To access the forum and subscribe to it, point your web browser to https://livebook.manning.com/#!/book/dependency-injection-principles-practices-patterns/discussion. You can also learn more about Manning’s forums and the rules of conduct at https://livebook.manning.com/#!/discussion.

Manning 对我们的读者的承诺是提供一个场所，让各个读者之间以及读者与作者之间可以进行有意义的对话。这不是对作者参与任何特定数量的承诺，他们对论坛的贡献仍然是自愿的（并且是无偿的）。我们建议您问他们一些具有挑战性的问题，以免他们的兴趣发生偏差！只要本书还在印刷，就可以从出版商的网站访问图书论坛和以前讨论的档案。

Manning’s commitment to our readers is to provide a venue where a meaningful dialogue between individual readers and between readers and the authors can take place. It isn’t a commitment to any specific amount of participation on the part of the authors, whose contribution to the forum remains voluntary (and unpaid). We suggest that you ask them some challenging questions lest their interest stray! The book forum and the archives of previous discussions will be accessible from the publisher’s website as long as the book is in print.

Steven van Deursen 是一位荷兰自由职业者 .NET 开发人员和架构师，自 2002 年以来一直在该领域工作。他住在奈梅亨，喜欢为乐趣和利润而编写代码。除了编写代码之外，Steven 还练习武术，喜欢外出就餐，当然也喜欢上一杯威士忌。

Steven van Deursen is a Dutch freelance .NET developer and architect with experience in the field since 2002. He lives in Nijmegen and enjoys writing code for fun and profit. Besides writing code, Steven trains in martial arts, likes to go out for food, and certainly fancies a good whiskey.

Mark Seemann 是一名程序员、软件架构师和演讲者，居住在丹麦哥本哈根。他从 1995 年开始从事软件工作，从 2003 年开始从事 TDD，包括在 Microsoft 工作六年，担任顾问、开发人员和架构师。Mark 目前专业从事软件开发，在哥本哈根工作。他喜欢阅读、绘画、弹吉他、美酒和美食。

Mark Seemann is a programmer, software architect, and speaker living in Copenhagen, Denmark. He has been working with software since 1995 and TDD since 2003, including six years with Microsoft as a consultant, developer, and architect. Mark is currently professionally engaged with software development and is working out of Copenhagen. He enjoys reading, painting, playing the guitar, good wine, and gourmet food.

在依赖注入原则、实践和模式的封面上是“来自 Vodnjan 的女人”，Vodnjan 是克罗地亚附近亚得里亚海伊斯特拉半岛内陆的一个小镇。该插图取自 Nikola Arsenovic 于 2003 年在克罗地亚斯普利特的民族志博物馆出版的 19 世纪中叶克罗地亚传统服饰相册的复制品。斯普利特本身位于中世纪城镇中心的罗马核心：公元 304 年左右的戴克里先皇帝退休宫殿的废墟。这本书包括克罗地亚不同地区人物的精美彩色插图，并附有服饰和日常生活。Vodnjan 是一个具有重要文化和历史意义的城镇，坐落在山顶上，可以欣赏到亚得里亚海的美丽景色，并以其众多的教堂和神圣艺术珍品而闻名。封面上的女人身穿黑色亚麻长裙，白色亚麻衬衫外罩黑色短夹克。这件夹克饰有蓝色刺绣，蓝色亚麻围裙使服装更加完美。女人还戴着一顶大沿黑帽，一条花围巾，戴着大圈形耳环。她优雅的服装表明她是城镇居民，而不是村庄居民。周边乡村的民间服饰色彩更艳丽，以羊毛为原料，饰有丰富的刺绣。女人还戴着一顶大沿黑帽，一条花围巾，戴着大圈形耳环。她优雅的服装表明她是城镇居民，而不是村庄居民。周边乡村的民间服饰色彩更艳丽，以羊毛为原料，饰有丰富的刺绣。女人还戴着一顶大沿黑帽，一条花围巾，戴着大圈形耳环。她优雅的服装表明她是城镇居民，而不是村庄居民。周边乡村的民间服饰色彩更艳丽，以羊毛为原料，饰有丰富的刺绣。

On the cover of Dependency Injection Principles, Practices, and Patterns is “A woman from Vodnjan,” a small town in the interior of the peninsula of Istria in the Adriatic Sea, off Croatia. The illustration is taken from a reproduction of an album of Croatian traditional costumes from the mid-nineteenth century by Nikola Arsenovic, published by the Ethnographic Museum in Split, Croatia, in 2003. The illustrations were obtained from a helpful librarian at the Ethnographic Museum in Split, itself situated in the Roman core of the medieval center of the town: the ruins of Emperor Diocletian’s retirement palace from around AD 304. The book includes finely colored illustrations of figures from different regions of Croatia, accompanied by descriptions of the costumes and of everyday life. Vodnjan is a culturally and historically significant town, situated on a hilltop with a beautiful view of the Adriatic and known for its many churches and treasures of sacral art. The woman on the cover wears a long, black linen skirt and a short, black jacket over a white linen shirt. The jacket is trimmed with blue embroidery, and a blue linen apron completes the costume. The woman is also wearing a large-brimmed black hat, a flowered scarf, and big hoop earrings. Her elegant costume indicates that she is an inhabitant of the town, rather than a village. Folk costumes in the surrounding countryside are more colorful, made of wool, and decorated with rich embroidery.

在过去的 200 年里，着装规范和生活方式发生了变化，当时如此丰富的地区多样性已经消失。现在很难区分不同大陆的居民，更不用说仅相隔几英里的不同小村庄或城镇了。也许我们已经用文化多样性换取了更加多样化的个人生活——当然是为了更加多样化和快节奏的技术生活。

Dress codes and lifestyles have changed over the last 200 years, and the diversity by region, so rich at the time, has faded away. It is now hard to tell apart the inhabitants of different continents, let alone of different hamlets or towns separated by only a few miles. Perhaps we have traded cultural diversity for a more varied personal life—certainly for a more varied and fast-paced technological life.

Manning 以两个世纪前地区生活的丰富多样性为基础，通过书籍封面来庆祝计算机行业的创造力和主动性，并通过像这本书这样的旧书和收藏中的插图将其带回生活。

Manning celebrates the inventiveness and initiative of the computer business with book covers based on the rich diversity of regional life of two centuries ago, brought back to life by illustrations from old books and collections like this one.

丁依赖注入 (DI) 是面向对象编程中最容易被误解的概念之一。混淆是丰富的，跨越术语、目的和机制。它应该被称为依赖注入、依赖反转、控制反转，还是第三方连接？DI 的目的仅仅是为了支持单元测试，还是有更广泛的目的？DI 与服务位置相同吗？我们是否需要DI 容器来应用 DI？

Dependency Injection (DI) is one of the most misunderstood concepts of object-oriented programming. The confusion is abundant and spans terminology, purpose, and mechanics. Should it be called Dependency Injection, Dependency Inversion, Inversion of Control, or even Third-Party Connect? Is the purpose of DI only to support unit testing, or is there a broader purpose? Is DI the same as Service Location? Do we need DI Containers to apply DI?

有很多讨论 DI 的博客文章、杂志文章、会议报告等，但不幸的是，其中许多使用了相互矛盾的术语或给出了错误的建议。整个行业都是如此，甚至像微软这样有影响力的大公司也加剧了混乱。

There are plenty of blog posts, magazine articles, conference presentations, and so on that discuss DI, but, unfortunately, many of them use conflicting terminology or give bad advice. This is true across the board, and even big and influential actors like Microsoft add to the confusion.

它不必是这样的。在本书中，我们呈现并使用一致的术语。在大多数情况下，我们采用并阐明了其他人定义的现有术语，但偶尔也会添加一些以前不存在的术语。这极大地帮助我们发展了 DI 范围或边界的规范。

It doesn’t have to be this way. In this book, we present and use a consistent terminology. For the most part, we’ve adopted and clarified existing terminology defined by others, but, occasionally, we add a bit of terminology where none existed previously. This has helped us tremendously in evolving a specification of the scope or boundaries of DI.

所有不一致和糟糕建议背后的根本原因之一是 DI 的界限非常模糊。DI 在哪里结束，其他面向对象的概念从哪里开始？我们认为不可能在 DI 和编写好的面向对象代码的其他方面之间划清界限。要谈论 DI，我们必须引入其他概念，例如SOLID、Clean Code，甚至Aspect-Oriented Programming。我们不认为我们可以在不涉及其他一些主题的情况下可靠地撰写有关 DI 的文章。

One of the underlying reasons behind all the inconsistency and bad advice is that the boundaries of DI are quite blurry. Where does DI end, and where do other object-oriented concepts begin? We think that it’s impossible to draw a distinct line between DI and other aspects of writing good object-oriented code. To talk about DI, we have to pull in other concepts such as SOLID, Clean Code, and even Aspect-Oriented Programming. We don’t feel that we can credibly write about DI without also touching on some of these other topics.

本书的第一部分帮助您了解 DI 相对于软件工程其他方面的位置——可以说，将其放在地图上。第 1 章让您快速浏览 DI，涵盖其目的、原则和好处，以及提供本书其余部分范围的大纲。它着眼于大局，并没有涉及很多细节。如果您想了解什么是 DI 以及为什么您应该对它感兴趣，那么这里就是您的起点。本章假设您之前没有 DI 知识。即使您已经了解 DI，您可能仍想阅读它——结果可能与您的预期不同。

The first part of the book helps you understand the place of DI in relation to other facets of software engineering — putting it on the map, so to speak. Chapter 1 gives you a quick tour of DI, covering its purpose, principles, and benefits, as well as providing an outline of the scope for the rest of the book. It’s focused on the big picture and doesn’t go into a lot of details. If you want to learn what DI is and why you should be interested in it, this is the place to start. This chapter assumes you have no prior knowledge of DI. Even if you already know about DI, you may still want to read it — it may turn out to be something other than what you expected.

另一方面，第 2 章和第 3 章完全留给一个大例子。此示例旨在让您对 DI 有更具体的感受。为了将 DI 与更传统的编程风格进行对比，第 2 章展示了示例电子商务应用程序的典型、紧密耦合的实现。第 3 章随后用 DI 重新实现它。

Chapters 2 and 3, on the other hand, are completely reserved for one big example. This example is intended to give you a much more concrete feel for DI. To contrast DI with a more traditional style of programming, chapter 2 showcases a typical, tightly coupled implementation of a sample e-commerce application. Chapter 3 then subsequently reimplements it with DI.

在这一部分中，我们将笼统地讨论 DI。这意味着我们不会使用任何所谓的DI Container。完全可以在不使用DI Container的情况下应用 DI 。DI 容器是一个有用但可选的工具。因此第 1、2 和 3 部分或多或少完全忽略了DI 容器，而是以与容器无关的方式讨论 DI。然后，在第 4 部分中，我们返回到DI 容器来剖析三个特定的库。

In this part, we’ll discuss DI in general terms. This means we won’t use any so-called DI Container. It’s entirely possible to apply DI without using a DI Container. A DI Container is a helpful, but optional, tool. So parts 1, 2, and 3 more or less ignore DI Containers completely, and instead discuss DI in a container-agnostic way. Then, in part 4, we return to DI Containers to dissect three specific libraries.

第 1 部分为本书的其余部分建立了上下文。它面向没有任何 DI 知识的读者，但经验丰富的 DI 从业者也可以通过浏览各章来了解整本书中使用的术语，从而从中受益。到第 1 部分结束时，您应该牢牢掌握词汇和整体概念，即使某些具体细节仍然有些模糊。没关系——随着您的阅读，本书变得更加具体，因此第 2、3 和 4 部分应该回答您在阅读第 1 部分后可能会遇到的问题。

Part 1 establishes the context for the rest of the book. It’s aimed at readers who don’t have any prior knowledge of DI, but experienced DI practitioners can also benefit from skimming the chapters to get a feeling for the terminology used throughout the book. By the end of part 1, you should have a firm grasp of the vocabulary and overall concepts, even if some of the concrete details are still a little fuzzy. That’s OK — the book becomes more concrete as you read on, so parts 2, 3, and 4 should answer the questions you’re likely to have after reading part 1.

在这一章当中

In this chapter

• 消除关于依赖注入的常见误解
• Dispelling common myths about Dependency Injection
• 理解依赖注入的目的
• Understanding the purpose of Dependency Injection
• 评估依赖注入的好处
• Evaluating the benefits of Dependency Injection
• 知道何时应用依赖注入
• Knowing when to apply Dependency Injection

您可能听说过制作贝恩酱酱很困难。即使在经常做饭的人中，也有许多人从未尝试过做饭。真可惜，因为酱汁很好吃。（它传统上与牛排搭配，但它也是白芦笋、荷包蛋和其他菜肴的绝佳搭配。）一些人求助于现成的酱汁或速溶混合物等替代品，但这些并不像真正的那样令人满意.

You may have heard that making a sauce béarnaise is difficult. Even among people who regularly cook, many have never attempted to make one. This is a shame, because the sauce is delicious. (It’s traditionally paired with steak, but it’s also an excellent accompaniment to white asparagus, poached eggs, and other dishes.) Some resort to substitutes like ready-made sauces or instant mixes, but these aren’t nearly as satisfying as the real thing.

蛋黄酱酱是一种由蛋黄和黄油制成的乳化酱汁，用龙蒿、山萝卜、青葱和醋调味。它不含水。制作它的最大挑战是它的准备工作可能会失败。酱汁会凝结或分离，如果发生任何一种情况，您将无法复活它。准备时间大约需要 45 分钟，因此尝试失败意味着您可能没有时间进行第二次尝试。在另一方面，任何厨师都可以制作蛋黄酱。这是他们训练的一部分，正如他们会告诉你的那样，这并不困难。

A sauce béarnaise is an emulsified sauce made from egg yolk and butter, that’s flavored with tarragon, chervil, shallots, and vinegar. It contains no water. The biggest challenge to making it is that its preparation can fail. The sauce can curdle or separate, and, if either happens, you can’t resurrect it. It takes about 45 minutes to prepare, so a failed attempt means that you may not have time for a second try. On the other hand, any chef can prepare a sauce béarnaise. It’s part of their training and, as they’ll tell you, it’s not difficult.

您无需成为专业厨师即可制作蛋黄酱。任何学习制作它的人都至少会失败一次，但是在掌握了它之后，您每次都会成功。我们认为依赖注入（DI）就像蛋黄酱。它被认为是困难的，而且，如果您尝试使用它但失败了，很可能没有时间进行第二次尝试。

You don’t have to be a professional cook to make sauce béarnaise. Anyone learning to make it will fail at least once, but after you get the hang of it, you’ll succeed every time. We think Dependency Injection (DI) is like sauce béarnaise. It’s assumed to be difficult, and, if you try to use it and fail, it’s likely there won’t be time for a second attempt.

尽管有恐惧、不确定和怀疑（恐惧症) 围绕 DI，就像制作贝恩酱一样简单易学。学习时可能会犯错误，但一旦掌握了技巧，就再也不会失败。

Despite the fear, uncertainty, and doubt (FUD) surrounding DI, it’s as easy to learn as making a sauce béarnaise. You may make mistakes while you learn, but once you’ve mastered the technique, you’ll never again fail to apply it successfully.

软件开发问答网站 Stack Overflow 对“如何向 5 岁的孩子解释依赖注入？”这个问题提供了答案。John Munsch 给出的评分最高的答案提供了一个针对（想象中的）五岁调查官的非常准确的类比：¹ 

Stack Overflow, the software development Q&A website, features an answer to the question, “How to explain Dependency Injection to a 5-year old?” The most highly rated answer, by John Munsch, provides a surprisingly accurate analogy targeted at the (imaginary) five-year-old inquisitor:¹ 

当您自己从冰箱中取出东西时，可能会引起问题。你可能会把门开着，你可能会得到妈妈或爸爸不希望你拥有的东西。您甚至可能正在寻找我们甚至没有或已经过期的东西。

When you go and get things out of the refrigerator for yourself, you can cause problems. You might leave the door open, you might get something Mommy or Daddy doesn’t want you to have. You might even be looking for something we don’t even have or which has expired.

你应该做的是陈述需求，“我需要在午餐时喝点东西，”然后我们会确保你坐下来吃饭时有东西喝。

What you should be doing is stating a need, “I need something to drink with lunch,” and then we will make sure you have something when you sit down to eat.

这在面向对象的软件开发方面意味着：协作类（五岁）应该依赖基础设施（父母）来提供必要的服务。

What this means in terms of object-oriented software development is this: collaborating classes (the five-year-old) should rely on infrastructure (the parents) to provide necessary services.

本章在结构上相当线性。首先，我们介绍 DI，包括它的目的和好处。尽管我们包含示例，但总的来说，本章的代码少于本书中的任何其他章节。在介绍 DI 之前，我们先讨论 DI 的基本目的——可维护性。这很重要，因为如果您没有做好充分准备，很容易误解 DI。接下来，在一个例子（你好 DI！）之后，我们讨论了好处和范围，为本书制定了路线图。完成本章后，您应该为本书其余部分中更高级的概念做好准备。

This chapter is fairly linear in structure. First, we introduce DI, including its purpose and benefits. Although we include examples, overall, this chapter has less code than any other chapter in the book. Before we introduce DI, we discuss the basic purpose of DI — maintainability. This is important because it’s easy to misunderstand DI if you aren’t properly prepared. Next, after an example (Hello DI!), we discuss benefits and scope, laying out a road map for the book. When you’re done with this chapter, you should be prepared for the more advanced concepts in the rest of the book.

对于大多数开发人员而言，DI 似乎是一种相当落后的创建源代码的方法，而且，就像蛋黄酱一样，其中涉及很多 FUD。要了解 DI，首先要了解它的用途。

To most developers, DI may seem like a rather backward way of creating source code, and, like sauce béarnaise, there’s much FUD involved. To learn about DI, you must first understand its purpose.

1.1 编写可维护的代码

1.1 Writing maintainable code

DI 的作用是什么？DI 本身不是目标；相反，它是达到目的的一种手段。归根结底，大多数编程技术的目的是尽可能高效地交付可工作的软件。其中一方面是编写可维护的代码。

What purpose does DI serve? DI isn’t a goal in itself; rather, it’s a means to an end. Ultimately, the purpose of most programming techniques is to deliver working software as efficiently as possible. One aspect of that is to write maintainable code.

除非您只编写原型或从未通过其第一个版本的应用程序，否则您会发现自己在维护和扩展现有代码库。为了有效地使用此类代码库，一般来说，它们的可维护性越高越好。

Unless you only write prototypes, or applications that never make it past their first release, you find yourself maintaining and extending existing code bases. To work effectively with such code bases, in general, the more maintainable they are, the better.

使代码更易于维护的一个极好的方法是通过松散耦合。早在 1994 年，当四人组编写设计模式时，这已经是常识：² 

An excellent way to make code more maintainable is through loose coupling. As far back as 1994, when the Gang of Four wrote Design Patterns, this was already common knowledge:² 

针对接口而不是实现编程。

Program to an interface, not an implementation.

这条重要的建议不是结论，而是设计模式的前提。松耦合使代码可扩展，可扩展性使其可维护。DI 只不过是一种支持松散耦合的技术。此外，关于 DI 存在许多误解，有时会妨碍正确理解。在你可以学习之前，你必须忘记你已经知道的（你认为的）东西。

This important piece of advice isn’t the conclusion, but, rather, the premise of Design Patterns. Loose coupling makes code extensible, and extensibility makes it maintainable. DI is nothing more than a technique that enables loose coupling. Moreover, there are many misconceptions about DI, and sometimes they get in the way of proper understanding. Before you can learn, you must unlearn what (you think) you already know.

1.1.1 关于 DI 的常见误解

1.1.1 Common myths about DI

您以前可能从未遇到或听说过 DI，这很好。跳过本节，直接进入 1.1.2 节。但是，如果您正在阅读本书，您可能至少在谈话中、在您继承的代码库中或在博客文章中遇到过它。您可能还注意到它带有相当多的严厉意见。在本节中，我们将探讨多年来出现的关于 DI 的四种最常见的误解，以及它们为何不正确。这些神话包括以下内容：

You may never have come across or heard of DI before, and that’s great. Skip this section and go straight to section 1.1.2. But, if you’re reading this book, it’s likely you’ve at least come across it in conversation, in a code base you inherited, or in blog posts. You may also have noticed that it comes with a fair amount of heavy opinions. In this section, we’re going to look at four of the most common misconceptions about DI that have appeared over the years and why they aren’t true. These myths include the following:

• DI 仅与后期绑定相关。
• DI is only relevant for late binding.
• DI 仅与单元测试相关。
• DI is only relevant for unit testing.
• DI 是一种类固醇抽象工厂。
• DI is a sort of Abstract Factory on steroids.
• DI 需要一个DI Container。
• DI requires a DI Container.

尽管这些神话都不是真的，但它们仍然很流行。在您开始了解 DI 之前，我们需要消除它们。

Although none of these myths are true, they’re prevalent nonetheless. We need to dispel them before you can start to learn about DI.

后期绑定

Late binding

在此上下文中，后期绑定是指无需重新编译代码即可替换应用程序部分的能力。启用第三方加载项的应用程序（例如 Visual Studio) 就是一个例子。另一个例子是支持不同运行环境的标准软件。

In this context, late binding refers to the ability to replace parts of an application without recompiling the code. An application that enables third-party add-ins (such as Visual Studio) is one example. Another example is the standard software that supports different runtime environments.

假设您有一个运行在多个数据库引擎上的应用程序（例如，同时支持 Oracle 和 SQL Server 的）。为了支持这个功能，应用程序的其余部分通过接口与数据库对话. 代码库提供了此接口的不同实现，以分别访问 Oracle 和 SQL Server。在这种情况下，您可以使用配置选项来控制给定安装应使用哪个实现。

Suppose you have an application that runs on more than one database engine (for example, one that supports both Oracle and SQL Server). To support this feature, the rest of the application talks to the database through an interface. The code base provides different implementations of this interface to access Oracle and SQL Server, respectively. In this case, you can use a configuration option to control which implementation should be used for a given installation.

一种常见的误解是 DI 仅与此类场景相关。这是可以理解的，因为 DI 支持这种情况。但谬论是认为这种关系是对称的。DI 启用后期绑定这一事实并不意味着它只与后期绑定场景相关。如图1.1所示，后期绑定只是 DI 的众多方面之一。

It’s a common misconception that DI is only relevant for this sort of scenario. That’s understandable, because DI enables this scenario. But the fallacy is to think that the relationship is symmetric. The fact that DI enables late binding doesn’t mean that it’s only relevant in late-binding scenarios. As figure 1.1 illustrates, late binding is only one of the many aspects of DI.

如果您认为 DI 仅与后期绑定场景相关，那么您需要忘却这一点。DI 的作用远不止启用后期绑定。

If you thought that DI was only relevant for late-binding scenarios, this is something you need to unlearn. DI does much more than enable late binding.

单元测试

Unit testing

有些人认为 DI 只与支持单元测试有关。这也不是真的，尽管 DI 肯定是支持单元测试的重要部分。说实话，我们最初对 DI 的介绍来自于与测试驱动开发的某些方面的斗争（测试驱动开发). 在那段时间里，我们发现了 DI 并了解到其他人已经使用它来支持我们正在处理的一些相同场景。

Some people think that DI is only relevant for supporting unit testing. This isn’t true, either, although DI is certainly an important part of support for unit testing. To tell you the truth, our original introduction to DI came from struggling with certain aspects of Test-Driven Development (TDD). During that time, we discovered DI and learned that other people had used it to support some of the same scenarios we were addressing.

即使您不编写单元测试（如果您不这样做，您应该现在就开始），DI 仍然很重要，因为它提供了所有其他好处。声称 DI 仅与支持单元测试相关就像声称它仅与支持后期绑定相关一样。图 1.2显示虽然这是一个不同的视图，但它是一个与图 1.1一样狭窄的视图。在本书中，我们将尽力向您展示全貌。

Even if you don’t write unit tests (if you don’t, you should start now), DI is still relevant because of all the other benefits it offers. Claiming that DI is only relevant for supporting unit testing is like claiming that it’s only relevant for supporting late binding. Figure 1.2 shows that although this is a different view, it’s a view as narrow as figure 1.1. In this book, we’ll do our best to show you the whole picture.

如果您认为 DI 仅与单元测试相关，请忘掉这个假设。DI 的作用远不止启用单元测试。

If you thought that DI was only relevant for unit testing, unlearn this assumption. DI does much more than enable unit testing.

类固醇的抽象工厂

An Abstract Factory on steroids

也许最危险的谬误是 DI 涉及某种通用的抽象工厂，您可以使用它来创建应用程序所需的依赖项的实例。

Perhaps the most dangerous fallacy is that DI involves some sort of general-purpose Abstract Factory that you can use to create instances of the Dependencies needed in your applications.

在本章的介绍中，我们写道“协作类应该依赖基础设施来提供必要的服务”。你对这句话的最初想法是什么？您是否将基础设施视为某种服务，您可以通过查询来获取所需的依赖项？如果是这样，你并不孤单。许多开发人员和架构师将 DI 视为可用于定位其他服务的服务。这称为服务定位器，但它与 DI 正好相反。

In the introduction to this chapter, we wrote that “collaborating classes should rely on infrastructure to provide necessary services.” What were your initial thoughts about this sentence? Did you think about infrastructure as some sort of service you could query to get the Dependencies you need? If so, you aren’t alone. Many developers and architects think about DI as a service that can be used to locate other services. This is called a Service Locator, but it’s the exact opposite of DI.

服务定位器通常被称为类固醇的抽象工厂，因为与普通的抽象工厂相比，可解析类型的列表是未指定的并且可能是无穷无尽的。它通常有一个方法允许创建各种类型，如下所示：

A Service Locator is often called an Abstract Factory on steroids because, compared to a normal Abstract Factory, the list of resolvable types is unspecified and possibly endless. It typically has one method allowing the creation of all sorts of types, much like in the following:

public interface IServiceLocator
{
    object GetService(Type serviceType);
}

DI容器

DI Containers

与先前的误解密切相关的是 DI 需要DI Container的概念。如果您之前错误地认为 DI 涉及Service Locator，那么很容易得出结论，DI Container可以承担Service Locator的责任。可能是这种情况，但这根本不是您应该如何使用DI Container。

Closely associated with the previous misconception is the notion that DI requires a DI Container. If you held the previous, mistaken belief that DI involves a Service Locator, then it’s easy to conclude that a DI Container can take on the responsibility of the Service Locator. This might be the case, but it’s not at all how you should use a DI Container.

DI 容器是一个可选的库，它可以让您在连接应用程序时更轻松地组合类，但这绝不是必需的。当您在没有DI Container的情况下编写应用程序时，它被称为Pure DI。这可能需要更多的工作，但除此之外，您不必在任何 DI 原则上妥协。

A DI Container is an optional library that makes it easier to compose classes when you wire up an application, but it’s in no way required. When you compose applications without a DI Container, it’s called Pure DI. It might take a little more work, but other than that, you don’t have to compromise on any DI principles.

我们还没有准确解释DI 容器是什么，以及您应该如何以及何时使用它。我们将在第 3 章末尾对此进行更详细的介绍；第 4 部分完全致力于此。

We have yet to explain exactly what a DI Container is, and how and when you should use it. We’ll go into more detail on this at the end of chapter 3; part 4 is completely dedicated to it.

您可能会认为，虽然我们已经揭露了关于 DI 的四个神话，但我们还没有对其中任何一个提出令人信服的理由。这是真的。从某种意义上说，这本书是对这些常见误解的有力论证，因此我们稍后肯定会回到这些主题。例如，在第 5 章中，5.2 节讨论了为什么使用Service Locator是一种反模式。

You may think that, although we’ve exposed four myths about DI, we have yet to make a compelling case against any of them. That’s true. In a sense, this book is one big argument against these common misconceptions, so we’ll certainly return to these topics later. For example, in chapter 5, section 5.2 discusses why Service Locator is an anti-pattern.

根据我们的经验，忘掉学习是至关重要的，因为人们经常试图改造我们告诉他们的关于 DI 的内容，并将其与他们认为自己已经知道的内容保持一致。当这种情况发生时，他们需要一段时间才能最终意识到他们的一些最基本的假设是错误的。我们不想让你有这种经历。如果可以，请像对 DI 一无所知一样阅读本书。

In our experience, unlearning is vital because people often try to retrofit what we tell them about DI and align it with what they think they already know. When this happens, it takes time before it finally dawns on them that some of their most basic assumptions are wrong. We want to spare you that experience. If you can, read this book as though you know nothing about DI.

1.1.2 理解 DI 的目的

1.1.2 Understanding the purpose of DI

DI 不是最终目标——它是达到目的的手段。DI 实现了松散耦合，松散耦合使代码更易于维护。这是一个相当大的说法，虽然我们可以将您推荐给像四人帮这样的权威机构以了解详细信息，但我们发现解释为什么这是真的是公平的。

DI isn’t an end goal — it’s a means to an end. DI enables loose coupling, and loose coupling makes code more maintainable. That’s quite a claim, and although we could refer you to well-established authorities like the Gang of Four for details, we find it only fair to explain why this is true.

为了传达这一信息，下一节将软件设计和几种软件设计模式与电线进行比较。我们发现这是一个强有力的类比。我们甚至用它来向非技术人员解释软件设计。

To get this message across, the next section compares software design and several software design patterns with electrical wiring. We’ve found this to be a powerful analogy. We even use it to explain software design to non-technical people.

我们在这个类比中使用了四种特定的设计模式，因为它们经常与 DI 相关。在整本书中，您会看到其中三种模式的许多示例——装饰器、合成器和适配器。（我们将在第 4 章介绍第四种模式，即 Null Object 模式。）如果您对这些模式还不是很熟悉，请不要担心：您将在本书的最后熟悉这些模式。

We use four specific design patterns in this analogy because they occur frequently in relation to DI. You’ll see many examples of three of these patterns — Decorator, Composite, and Adapter — throughout this book. (We cover the fourth, the Null Object pattern, in chapter 4.) Don’t worry if you’re not that familiar with these patterns: you will be by the end of the book.

软件开发仍然是一个相当新的职业，所以在很多方面我们仍在弄清楚如何实现良好的架构。但是，在更传统的行业（如建筑）中具有专业知识的人很久以前就想通了。

Software development is still a rather new profession, so in many ways we’re still figuring out how to implement good architecture. But individuals with expertise in more traditional professions (such as construction) figured it out a long time ago.

入住廉价酒店

Checking into a cheap hotel

如果你住在便宜的旅馆，你可能会遇到如图 1.3 所示的景象。在这里，为了您的方便，酒店好心地提供了吹风机，但显然他们不信任您将吹风机留给下一位客人：该设备直接连接到墙上的插座。酒店管理层认为，更换被盗吹风机的成本高到足以证明在其他情况下实施明显较差的做法是合理的。

If you’re staying at a cheap hotel, you might encounter a sight like the one in figure 1.3. Here, the hotel has kindly provided a hair dryer for your convenience, but apparently they don’t trust you to leave the hair dryer for the next guest: the appliance is directly attached to the wall outlet. The hotel management decided that the cost of replacing stolen hair dryers is high enough to justify what’s otherwise an obviously inferior implementation.

当吹风机停止工作时会发生什么？酒店必须请一位技术娴熟的专业人员。要修理固定接线的吹风机，必须切断房间的电源，使其暂时无法使用。然后，技术人员必须使用特殊工具断开吹风机的连接，并更换新的吹风机。如果你幸运的话，技术人员会记得重新打开房间的电源，然后回去测试新吹风机是否工作——如果你幸运的话。这个过程听起来很熟悉吗？

What happens when the hair dryer stops working? The hotel has to call in a skilled professional. To fix the hardwired hair dryer, the power to the room will have to be cut, rendering it temporarily useless. Then, the technician must use special tools to disconnect the hair dryer and replace it with a new one. If you’re lucky, the technician will remember to turn the power to the room back on and go back to test whether the new hair dryer works — if you’re lucky. Does this procedure sound at all familiar?

这就是您处理紧密耦合代码的方法。在这种情况下，吹风机与墙壁紧密相连，您无法在不影响另一个的情况下轻松修改其中一个。

This is how you would approach working with tightly coupled code. In this scenario, the hair dryer is tightly coupled to the wall, and you can’t easily modify one without impacting the other.

将电线与设计模式进行比较

Comparing electrical wiring to design patterns

通常，我们不会通过将电缆直接连接到墙上来将电器连接在一起。相反，如图 1.4 所示，我们使用插头和插座。插座定义了插头必须匹配的形状。

Usually, we don’t wire electrical appliances together by attaching the cable directly to the wall. Instead, as in figure 1.4, we use plugs and sockets. A socket defines a shape that the plug must match.

类比于软件设计，插座是一个接口，而插头及其设备是一个实现。这意味着房间（应用程序）有一个或（希望）多个插座，房间的用户（开发人员）可以随心所欲地插入电器，甚至可能是客户提供的吹风机。

In an analogy to software design, the socket is an interface, and the plug with its appliance is an implementation. This means that the room (the application) has one or (hopefully) more sockets, and the users of the room (the developers) can plug in appliances as they please, potentially even a customer-supplied hair dryer.

与硬连线吹风机相比，插头和插座定义了一种用于连接电器的松散耦合模型。只要插头（实现）适合插座（实现接口），并且它可以处理伏特和赫兹的量（遵守接口契约），我们就可以以多种方式组合电器。特别有趣的是，许多这些常见的组合可以与众所周知的软件设计原则和模式进行比较。

In contrast to the hardwired hair dryer, plugs and sockets define a loosely coupled model for connecting electrical appliances. As long as the plug (the implementation) fits into the socket (implements the interface), and it can handle the amount of volts and hertz (obeys the interface contract), we can combine appliances in a variety of ways. What’s particularly interesting is that many of these common combinations can be compared to well-known software design principles and patterns.

首先，我们不再局限于吹风机。如果您是普通读者，我们会猜测您对计算机的需求远远超过对吹风机的需求。这不是问题：你拔掉吹风机的插头，然后把电脑的插头插到同一个插座上（图 1.5）。

First, we’re no longer constrained to hair dryers. If you’re an average reader, we would guess that you need power for a computer much more than you do for a hair dryer. That’s not a problem: you unplug the hair dryer and plug a computer into the same socket (figure 1.5).

如果您暂时不需要使用计算机，您可以拔掉它。即使没有插入任何东西，房间也不会爆炸。也就是说，如果你把电脑的插头从墙上拔下来，墙上的插座和电脑都不会坏。

You can unplug the computer if you don’t need to use it at the moment. Even though nothing is plugged in, the room doesn’t explode. That is to say, if you unplug the computer from the wall, neither the wall outlet nor the computer breaks down.

但是，对于软件，客户通常希望获得可用的服务。如果您删除该服务，您将获得一个. 要处理这种情况，您可以创建一个不执行任何操作的接口实现。这种称为Null Object的设计模式对应于儿童安全插座插头（没有电线或电器但仍可插入插座的插头）。而且因为您使用的是松散耦合，所以您可以用不做任何事情的东西替换真正的实现而不会引起麻烦。如图 1.6所示。NullReferenceException

With software, however, a client often expects a service to be available. If you remove the service, you get a NullReferenceException. To deal with this type of situation, you can create an implementation of an interface that does nothing. This design pattern, known as Null Object, corresponds to having a children’s safety outlet plug (a plug without a wire or appliance that still fits into the socket). And because you’re using loose coupling, you can replace a real implementation with something that does nothing without causing trouble. This is illustrated in figure 1.6.

您还可以做许多其他事情。如果您住在间歇性停电的社区，您可能希望通过插入不间断电源来保持计算机运行（UPS). 如图 1.7所示，您将 UPS 连接到墙上插座，将计算机连接到 UPS。

There are many other things you can do, as well. If you live in a neighborhood with intermittent power failures, you may want to keep the computer running by plugging in into an uninterrupted power supply (UPS). As shown in figure 1.7, you connect the UPS to the wall outlet and the computer to the UPS.

计算机和 UPS 有不同的用途。每个人都有一个不侵犯另一个单位的单一责任。UPS和电脑很可能是两个不同厂家生产的，不同时间买的，分开插的。如图1.5所示，您可以在没有 UPS 的情况下运行计算机，并且您也可以想象在停电期间通过将其插入 UPS 来使用吹风机。

The computer and the UPS serve separate purposes. Each has a Single Responsibility that doesn’t infringe on the other unit. The UPS and computer are likely to be produced by two different manufacturers, bought at different times, and plugged in separately. As figure 1.5 demonstrated, you can run the computer without a UPS, and you could also conceivably use the hair dryer during blackouts by plugging it into the UPS.

在软件设计中，这种用同一接口的另一个实现拦截一个实现的方式被称为装饰器设计模式。⁵  它使您能够逐步引入新功能和横切关注点无需重写或更改大量现有代码。

In software design, this way of intercepting one implementation with another implementation of the same interface is known as the Decorator design pattern.⁵  It gives you the ability to incrementally introduce new features and Cross-Cutting Concerns without having to rewrite or change a lot of existing code.

向现有代码库添加新功能的另一种方法是使用新实现重构接口的现有实现。当您将多个实现聚合为一个时，您使用复合设计模式. ⁶  图 1.8说明了这与将不同的电器插入电源板是如何对应的。

Another way to add new functionality to an existing code base is to refactor an existing implementation of an interface with a new implementation. When you aggregate several implementations into one, you use the Composite design pattern.⁶  Figure 1.8 illustrates how this corresponds to plugging diverse appliances into a power strip.

配电盘只有一个插头，您可以将其插入一个插座，配电盘本身为各种电器提供多个插座。这使您可以在计算机运行时添加和移除吹风机。以同样的方式，复合模式使得通过修改组合接口实现集来添加或删除功能变得容易。

The power strip has a single plug that you can insert into a single socket, and the power strip itself provides several sockets for a variety of appliances. This enables you to add and remove the hair dryer while the computer is running. In the same way, the Composite pattern makes it easy to add or remove functionality by modifying the set of composed interface implementations.

这是最后一个例子。有时您会发现自己处于插头不适合特定插座的情况。如果您去过另一个国家/地区，您可能会注意到世界各地的插座各不相同。如果你在旅行时随身携带类似图 1.9中的相机的东西，你将需要一个适配器来给它充电。适当地，有一个同名的设计模式。

Here’s a final example. You sometimes find yourself in situations where a plug doesn’t fit into a particular socket. If you’ve traveled to another country, you’ve likely noticed that sockets differ across the world. If you bring something like the camera in figure 1.9 along when traveling, you’ll need an adapter to charge it. Appropriately, there’s a design pattern with the same name.

适配器设计模式就像它的物理同名一样工作。⁷  您可以使用它来匹配两个相关但独立的接口。当您有一个现有的第三方 API，您希望将其公开为您的应用程序使用的接口的实例时，这尤其有用。与物理适配器一样，适配器设计模式的实现可以从简单到极其复杂。

The Adapter design pattern works like its physical namesake.⁷  You can use it to match two related, yet separate, interfaces to each other. This is particularly useful when you have an existing third-party API that you want to expose as an instance of an interface your application consumes. As with the physical adapter, implementations of the Adapter design pattern can range from simple to extremely complex.

插座和插头模型的惊人之处在于，几十年来，它被证明是一种简单且用途广泛的模型。一旦基础设施到位，它就可以被使用任何人并适应不断变化的需求和意外要求。更有趣的是，当我们将此模型与软件开发相关联时，所有构建块都已经以设计原则和模式的形式就位。

What’s amazing about the socket and plug model is that, over decades, it’s proven to be an easy and versatile model. Once the infrastructure is in place, it can be used by anyone and adapted to changing needs and unanticipated requirements. What’s even more interesting is that, when we relate this model to software development, all the building blocks are already in place in the form of design principles and patterns.

松散耦合在软件设计中的优势与在物理插座和插头模型中的优势相同：一旦基础设施到位，任何人都可以使用它并适应不断变化的需求和不可预见的要求，而无需对应用程序进行大的更改代码库和基础设施。这意味着理想情况下，新需求应该只需要添加一个新类，而无需更改系统中其他已经存在的类。

The advantage of loose coupling is the same in software design as it is in the physical socket and plug model: Once the infrastructure is in place, it can be used by anyone and adapted to changing needs and unforeseen requirements without requiring large changes to the application code base and infrastructure. This means that ideally, a new requirement should only necessitate the addition of a new class, with no changes to other already-existing classes of the system.

这种能够在不修改现有代码的情况下扩展应用程序的概念称为开放/封闭原则. 不可能达到 100% 的代码始终对可扩展性开放而对修改关闭的情况。不过，松散耦合确实会让您更接近该目标。

This concept of being able to extend an application without modifying existing code is called the Open/Closed Principle. It’s impossible to get to a situation where 100% of your code will always be open for extensibility and closed for modification. Still, loose coupling does bring you closer to that goal.

而且，随着每一步，向您的系统添加新功能和要求变得更加容易。能够在不触及系统现有部分的情况下添加新功能意味着问题是孤立的。这导致代码更易于理解和测试，使您能够管理系统的复杂性。这就是松散耦合可以为您提供帮助的原因，也是它可以使代码库更易于维护的原因。我们将在第 4 章中更详细地讨论开闭原则。

And, with every step, it gets easier to add new features and requirements to your system. Being able to add new features without touching existing parts of the system means that problems are isolated. This leads to code that’s easier to understand and test, allowing you to manage the complexity of your system. That’s what loose coupling can help you with, and that’s why it can make a code base much more maintainable. We’ll discuss the Open/Closed Principle in more detail in chapter 4.

到目前为止，您可能想知道这些模式在代码中实现时的外观。别担心。如前所述，我们将在整本书中向您展示这些模式的大量示例。事实上，在本章的后面，我们将向您展示装饰器模式和适配器模式的实现。

By now you might be wondering how these patterns will look when implemented in code. Don’t worry about that. As we stated before, we’ll show you plenty of examples of those patterns throughout this book. In fact, later in this chapter, we’ll show you an implementation of both the Decorator and Adapter patterns.

松散耦合的简单部分是针对接口而不是实现进行编程。问题是，“实例来自哪里？” 从某种意义上说，这就是整本书的主题：这是 DI 试图回答的核心问题。

The easy part of loose coupling is programming to an interface instead of an implementation. The question is, “Where do the instances come from?” In a sense, this is what this entire book is about: it’s the core question that DI seeks to answer.

您不能像创建具体类型的新实例那样创建接口的新实例。像这样的代码无法编译：

You can’t create a new instance of an interface the same way that you create a new instance of a concrete type. Code like this doesn’t compile:

接口不包含任何实现，因此这是不可能的。writer实例_必须使用不同的机制创建。DI 解决了这个问题。有了这个 DI 目的的概述，我们认为您已经准备好举个例子了。

An interface contains no implementation, so this isn’t possible. The writer instance must be created using a different mechanism. DI solves this problem. With this outline of the purpose of DI, we think you’re ready for an example.

1.2 一个简单的例子：你好DI！

1.2 A simple example: Hello DI!

在无数编程教科书的传统中，让我们来看看一个简单的控制台应用程序，上面写着“Hello DI！” 到屏幕。请注意，完整代码可作为本书下载的一部分提供，如本书开头的“代码约定和下载”部分所述。

In the tradition of innumerable programming textbooks, let’s take a look at a simple console application that writes “Hello DI!” to the screen. Note that the full code is available as part of the download for this book, as mentioned in the section “Code conventions and downloads” at the beginning of this book.

在本节中，我们将向您展示代码的外观，并简要概述一些主要优点，但不深入细节。在本书的其余部分，我们将更加具体。

In this section, we’ll show you what the code looks like and briefly outline some key benefits without going into details. In the rest of the book, we’ll get more specific.

1.2.1 你好迪！代码

1.2.1 Hello DI! code

您可能习惯于看到用一行代码编写的 Hello World 示例。在这里，我们将把一些非常简单的东西变得更复杂。为什么？我们很快就会谈到这一点，但让我们先看看 Hello World 使用 DI 会是什么样子。

You’re probably used to seeing Hello World examples that are written with a single line of code. Here, we’ll take something that’s extremely simple and make it more complicated. Why? We’ll get to that shortly, but let’s first see what Hello World would look like with DI.

合作者

Collaborators

为了了解程序的结构，我们将从查看Main方法开始控制台应用程序。然后我们将向您展示协作类；但首先，这是MainHello DI 的方法！应用：

To get a sense of the structure of the program, we’ll start by looking at the Main method of the console application. Then we’ll show you the collaborating classes; but first, here’s the Main method of the Hello DI! application:

private static void Main()
{
    IMessageWriter writer = new ConsoleMessageWriter();
    var salutation = new Salutation(writer);
    salutation.Exclaim();
}

因为程序需要写入控制台，所以它创建了一个封装该功能的新实例。它将那个消息编写器传递给类ConsoleMessageWriterSalutation这样称呼实例就知道在哪里写它的消息。因为现在一切都已正确连接，您可以通过Exclaim方法执行逻辑，从而将消息写入屏幕。

Because the program needs to write to the console, it creates a new instance of ConsoleMessageWriter that encapsulates that functionality. It passes that message writer to the Salutation class so that the salutation instance knows where to write its messages. Because everything is now wired up properly, you can execute the logic via the Exclaim method, which results in the message being written to the screen.

Main方法内部对象的构造是纯 DI的基本示例. 没有DI 容器用于组成Salutation及其依赖项。图 1.10显示了协作者之间的关系。ConsoleMessageWriter

The construction of objects inside the Main method is a basic example of Pure DI. No DI Container is used to compose the Salutation and its ConsoleMessageWriter Dependency. Figure 1.10 shows the relationship between the collaborators.

实现应用程序逻辑

Implementing the application logic

应用的主要逻辑封装在Salutation类中，如清单 1.1所示。

The main logic of the application is encapsulated in the Salutation class, shown in listing 1.1.

Listing 1.1 Salutation类封装了主要的应用逻辑

Listing 1.1 Salutation class encapsulates the main application logic

public class Salutation
{
    private readonly IMessageWriter writer;

    public Salutation(IMessageWriter writer)    ①  
    {
        if (writer == null)    ②  
            throw new ArgumentNullException("writer");  ②  

        this.writer = writer;
    }

    public void Exclaim()
    {
        this.writer.Write("Hello DI!");    ③  
    }
}

Salutation班级_取决于一个名为（接下来定义）的自定义接口。它通过其构造函数请求它的一个实例。这种做法称为构造函数注入IMessageWriter. 保护条款IMessageWriter通过抛出异常 来验证提供的不为空。⁸  最后，您在方法IMessageWriter的实现中使用之前注入的实例Exclaim通过调用它的Write方法. 这会发送 Hello DI！消息到IMessageWriter Dependency。

The Salutation class depends on a custom interface called IMessageWriter (defined next). It requests an instance of it through its constructor. This practice is called Constructor Injection. A Guard Clause verifies that the supplied IMessageWriter isn’t null by throwing an exception if it is.⁸  And, finally, you use the previously injected IMessageWriter instance inside the implementation of the Exclaim method by calling its Write method. This sends the Hello DI! message to the IMessageWriter Dependency.

用 DI 术语来说，我们说IMessageWriter Dependency被注入到Salutation类中使用构造函数参数。请注意，Salutation没有意识。它仅通过界面与之交互。是为该场合定义的简单接口：ConsoleMessageWriterIMessageWriterIMessageWriter

To speak in DI terminology, we say that the IMessageWriter Dependency is injected into the Salutation class using a constructor argument. Note that Salutation has no awareness of ConsoleMessageWriter. It interacts with it exclusively through the IMessageWriter interface. IMessageWriter is a simple interface defined for the occasion:

public interface IMessageWriter
{
    void Write(string message);
}

它可能有其他成员，但在这个简单的示例中，您只需要Write方法。它由ConsoleMessageWriter类实现该Main方法传递给Salutation类：

It could have had other members, but in this simple example, you only need the Write method. It’s implemented by the ConsoleMessageWriter class that the Main method passes to the Salutation class:

public class ConsoleMessageWriter : IMessageWriter
{
    public void Write(string message)
    {
        Console.WriteLine(message);
    }
}

ConsoleMessageWriter类通过IMessageWriter包装Console类实现.NET 基类库（BCL）。这是我们在 1.1.2 节中谈到的适配器设计模式的简单应用。

The ConsoleMessageWriter class implements IMessageWriter by wrapping the Console class of the .NET Base Class Library (BCL). This is a simple application of the Adapter design pattern that we talked about in section 1.1.2.

1.2.2 DI 的好处

1.2.2 Benefits of DI

您可能想知道将一行代码替换为两个类和一个接口（总共 28 行）的好处。您可以轻松解决与此处所示相同的问题：

You may be wondering about the benefit of replacing a single line of code with two classes and an interface, resulting in 28 lines total. You could easily solve the same problem as shown here:

private static void Main()
{
    Console.WriteLine("Hello DI!");
}

DI 可能看起来有点矫枉过正，但使用它有几个好处。前面的示例与通常用于在 C# 中实现 Hello World 的单行代码相比有何优势？在此示例中，DI 增加了 2800% 的开销，但是，随着复杂性从一行代码增加到数万行，这种开销会减少甚至消失。第 3 章提供了一个更复杂的应用 DI 示例。尽管与现实生活中的应用程序相比，该示例仍然过于简单，但您应该注意到 DI 的侵入性要小得多。

DI might seem like overkill, but there are several benefits to be harvested from using it. How is the previous example better than the usual single line of code you normally use to implement Hello World in C#? In this example, DI adds an overhead of 2800%, but, as complexity increases from one line of code to tens of thousands, this overhead diminishes and all but disappears. Chapter 3 provides a more complex example of applied DI. Although that example is still overly simplistic compared to real-life applications, you should notice that DI is far less intrusive.

如果您发现前面的 DI 示例设计过度，我们不会责怪您，但考虑一下：就其本质而言，经典的 Hello World 示例是一个简单的问题，具有明确指定和约束的要求。在现实世界中，软件开发从来都不是这样的。需求不断变化，而且常常是模糊的。您必须实现的功能也往往要复杂得多。DI 通过启用松散耦合来帮助解决此类问题。具体来说，您将获得表 1.1中列出的好处。

We don’t blame you if you find the previous DI example to be over-engineered, but consider this: by its nature, the classic Hello World example is a simple problem with well-specified and constrained requirements. In the real world, software development is never like this. Requirements change and are often fuzzy. The features you must implement also tend to be much more complex. DI helps address such issues by enabling loose coupling. Specifically, you gain the benefits listed in table 1.1.

我们首先列出了后期绑定的好处，因为根据我们的经验，这是大多数人心中最重要的好处。当架构师和开发人员未能理解松散耦合的好处时，很可能是因为他们从未考虑过其他好处。

We listed the late-binding benefit first because, in our experience, this is the one that’s foremost in most people’s minds. When architects and developers fail to understand the benefits of loose coupling, it’s most likely because they never consider the other benefits.

后期绑定

Late binding

当我们向接口和 DI 解释编程的好处时，将一种服务换成另一种服务的能力对大多数人来说是最显着的好处，因此他们往往只考虑这个好处来权衡利弊。还记得我们建议您在学习之前可能需要忘却吗？您可能会说您非常了解自己的需求，以至于您永远不必用其他任何东西替换，比如说，您的 SQL Server 数据库。但是要求会改变。

When we explain the benefits of programming to interfaces and DI, the ability to swap out one service with another is the most conspicuous benefit for most people, so they tend to weigh the advantages against the disadvantages with only this benefit in mind. Remember when we suggested that you may need to unlearn before you can learn? You may say that you know your requirements so well that you know you’ll never have to replace, say, your SQL Server database with anything else. But requirements change.

在 1.2.1 节中，您没有使用后期绑定，因为您通过对新实例的创建进行硬编码来显式创建了一个新实例。但是，您可以通过更改这一行代码来引入后期绑定：IMessageWriterConsoleMessageWriter

In section 1.2.1, you didn’t use late binding because you explicitly created a new instance of IMessageWriter by hard coding the creation of a new ConsoleMessageWriter instance. You can, however, introduce late binding by changing this single line of code:

IMessageWriter writer = new ConsoleMessageWriter();

要启用后期绑定，您可以将该行代码替换为类似以下内容。

To enable late binding, you might replace that line of code with something like the following.

清单 1.2 延迟绑定IMessageWriter实现

Listing 1.2 Late binding an IMessageWriter implementation

IConfigurationRoot configuration = new ConfigurationBuilder()
    .SetBasePath(Directory.GetCurrentDirectory())
    .AddJsonFile("appsettings.json")
    .Build();

string typeName = configuration["messageWriter"];
Type type = Type.GetType(typeName, throwOnError: true);

IMessageWriter writer = (IMessageWriter)Activator.CreateInstance(type);

通过从应用程序配置文件中提取类型名称并创建一个Type实例从中，您可以使用反射创建一个实例，而无需在编译时知道具体类型。要使其工作，您在应用程序中指定类型名称IMessageWritermessageWriter在应用程序配置文件中设置：

By pulling the type name from the application configuration file and creating a Type instance from it, you can use reflection to create an instance of IMessageWriter without knowing the concrete type at compile time. To make this work, you specify the type name in the messageWriter application setting in the application configuration file:

{
  "messageWriter":
    "Ploeh.Samples.HelloDI.Console.ConsoleMessageWriter, HelloDI.Console"
}

松散耦合支持后期绑定，因为只有一个地方可以创建IMessageWriter. 因为Salutation班专门针对IMessageWriter界面工作，它永远不会注意到差异。在你好 DI！例如，后期绑定将使您能够将消息写入与控制台不同的目的地；例如，数据库或文件。添加此类功能是可能的——即使您没有提前明确计划它们。

Loose coupling enables late binding because there’s only a single place where you create the instance of IMessageWriter. Because the Salutation class works exclusively against the IMessageWriter interface, it never notices the difference. In the Hello DI! example, late binding would enable you to write the message to a different destination than the console; for example, a database or a file. It’s possible to add such features — even though you didn’t explicitly plan ahead for them.

可扩展性

Extensibility

成功的软件必须能够改变。您需要添加新功能并扩展现有功能。松散耦合让您可以高效地重构应用程序，类似于您在使用电插头和插座时的灵活性。

Successful software must be able to change. You’ll need to add new features and extend existing features. Loose coupling lets you efficiently recompose the application, similar to the way you have flexibility when working with electrical plugs and sockets.

假设您想制作 Hello DI！通过仅允许经过身份验证的用户编写消息来更安全的示例。清单 1.3显示了如何在不更改任何现有功能的情况下添加该功能——您只需添加一个新的IMessageWriter接口实现。

Let’s say that you want to make the Hello DI! example more secure by only allowing authenticated users to write the message. Listing 1.3 shows how you can add that feature without changing any of the existing features — you simply add a new implementation of the IMessageWriter interface.

清单 1.3 扩展 Hello DI！应用具有安全功能

Listing 1.3 Extending the Hello DI! application with a security feature

public class SecureMessageWriter : IMessageWriter    ①  
{
    private readonly IMessageWriter writer;
    private readonly IIdentity identity;

    public SecureMessageWriter(
        IMessageWriter writer,    ②  
        IIdentity identity)
    {
        if (writer == null)
            throw new ArgumentNullException("writer");
        if (identity == null)
            throw new ArgumentNullException("identity");

        this.writer = writer;
        this.identity = identity;
    }

    public void Write(string message)
    {
        if (this.identity.IsAuthenticated)    ③  
        {
            this.writer.Write(message);    ④  
        }
    }
}

除了 的实例之外IMessageWriter，构造函数还需要 的实例。该方法是通过首先使用注入的. 如果是这种情况，它允许将修饰的编写器字段添加到消息中。唯一需要更改现有代码的地方是在方法中，因为您需要以不同于以前的方式组合可用的类：SecureMessageWriterIIdentityWriteIIdentityWriteMain

Besides an instance of IMessageWriter, the SecureMessageWriter constructor requires an instance of IIdentity. The Write method is implemented by first checking whether the current user is authenticated, using the injected IIdentity. If this is the case, it allows the decorated writer field to Write the message. The only place where you need to change existing code is in the Main method, because you need to compose the available classes differently than before:

IMessageWriter writer =
    new SecureMessageWriter(    ①  

        new ConsoleMessageWriter(),
        WindowsIdentity.GetCurrent());

请注意，您用新类包装或装饰了旧实例ConsoleMessageWriterSecureMessageWriter. 再一次，Salutation该类未被修改，因为它只使用IMessageWriter接口. 同样，无需修改或复制ConsoleWriter类中的功能， 任何一个。你使用System.Security.Principal.WindowsIdentity类检索代表其执行此代码的用户的身份。¹⁰ 

Notice that you wrap or decorate the old ConsoleMessageWriter instance with the new SecureMessageWriter class. Once more, the Salutation class is unmodified because it only consumes the IMessageWriter interface. Similarly, there’s no need to either modify or duplicate the functionality in the ConsoleWriter class, either. You use the System.Security.Principal.WindowsIdentity class to retrieve the identity of the user on whose behalf this code is being executed.¹⁰ 

正如我们之前所述，松散耦合使您能够编写对可扩展性开放但对修改关闭的代码。唯一需要修改代码的地方是在应用程序入口点。实现应用程序的安全功能，同时处理用户界面。这使您能够独立地改变这些方面，并根据需要组合它们。每个类都有自己的单一职责。SecureMessageWriterConsoleMessageWriter

As we’ve stated before, loose coupling enables you to write code that’s open for extensibility, but closed for modification. The only place where you need to modify the code is at the application entry point. SecureMessageWriter implements the security features of the application, whereas ConsoleMessageWriter addresses the user interface. This enables you to vary these aspects independently of each other and compose them as needed. Each class has its own Single Responsibility.

并行开发

Parallel development

关注点分离使得并行开发代码成为可能。当一个软件开发项目发展到一定规模时，就需要有多个开发人员在同一代码库上并行工作。在更大的规模上，甚至有必要将开发团队分成多个规模可管理的团队。每个团队通常被分配负责整个应用程序的一个区域。为了划分职责，每个团队开发一个或多个模块，这些模块需要集成到完成的应用程序中。除非每个团队的领域真正独立，否则某些团队可能会依赖其他团队开发的功能。

Separation of concerns makes it possible to develop code in parallel. When a software development project grows to a certain size, it becomes necessary to have multiple developers work in parallel on the same code base. At a larger scale, it’s even necessary to separate the development team into multiple teams of manageable sizes. Each team is often assigned responsibility for an area of the overall application. To demarcate responsibilities, each team develops one or more modules that will need to be integrated into the finished application. Unless the areas of each team are truly independent, some teams are likely to depend on functionality developed by other teams.

在前面的示例中，因为和类不直接相互依赖，所以它们可以由并行团队开发。他们需要就共享接口达成一致。SecureMessageWriterConsoleMessageWriterIMessageWriter

In the previous example, because the SecureMessageWriter and ConsoleMessageWriter classes don’t depend directly on each other, they could’ve been developed by parallel teams. All they would have needed to agree on was the shared interface IMessageWriter.

可维护性

Maintainability

随着每个类的职责得到明确定义和约束，整个应用程序的维护变得更加容易。这是单一职责原则的结果，它指出每个类应该只有一个责任。我们将在第 2 章中更详细地讨论单一职责原则。

As the responsibility of each class becomes clearly defined and constrained, maintenance of the overall application becomes easier. This is a consequence of the Single Responsibility Principle, which states that each class should have only a single responsibility. We’ll discuss the Single Responsibility Principle in more detail in chapter 2.

向应用程序添加新功能变得更加简单，因为很清楚应该在何处应用更改。通常情况下，您不需要更改现有代码，而是可以添加新类并重构应用程序。这就是开闭原则再次行动。

Adding new features to an application becomes simpler because it’s clear where changes should be applied. More often than not, you don’t need to change existing code, but can instead add new classes and recompose the application. This is the Open/Closed Principle in action again.

故障排除也往往变得不那么费力，因为可能的罪魁祸首的范围缩小了。有了明确定义的职责，您通常会很清楚从哪里开始寻找问题的根本原因。

Troubleshooting also tends to become less grueling, because the scope of likely culprits narrows. With clearly defined responsibilities, you’ll often have a good idea of where to start looking for the root cause of a problem.

可测试性

Testability

当一个应用程序可以进行单元测试时，它被认为是可测试的。对于某些人来说，可测试性是他们最不担心的事情；对于其他人来说，这是绝对的要求。就个人而言，我们属于后一类。在 Mark 的职业生涯中，他拒绝了几份工作邀请，因为这些工作涉及使用某些不可测试的产品。

An application is considered Testable when it can be unit tested. For some, Testability is the least of their worries; for others, it’s an absolute requirement. Personally, we belong in the latter category. In Mark’s career, he’s declined several job offers because they involved working with certain products that weren’t Testable.

可测试性的好处可能是我们列出的那些中最具争议的。一些开发人员和架构师仍然不进行单元测试，因此他们充其量认为这种好处无关紧要。然而，我们将其视为软件开发的重要组成部分，这就是为什么我们在表 1.1中将其标记为“始终有价值” 。Michael Feathers 甚至定义了遗留应用程序这个术语与单元测试未涵盖的任何应用程序一样。¹¹ 

The benefit of Testability is perhaps the most controversial of those we’ve listed. Some developers and architects still don’t practice unit testing, so they consider this benefit irrelevant at best. We, however, see it as an essential part of software development, which is why we marked it as “Always valuable” in table 1.1. Michael Feathers even defines the term legacy application as any application that isn’t covered by unit tests.¹¹ 

几乎是偶然的，松散耦合使单元测试成为可能，因为消费者遵循里氏替换原则：他们不关心依赖项的具体类型。这意味着您可以将测试替身注入被测系统(被测物)，正如您将在清单 1.4中看到的那样。

Almost by accident, loose coupling enables unit testing because consumers follow the Liskov Substitution Principle: they don’t care about the concrete types of their Dependencies. This means that you can inject Test Doubles into the System Under Test (SUT), as you’ll see in listing 1.4.

用特定于测试的替换替换预期的依赖项的能力是松散耦合的副产品，但我们选择将其列为单独的好处，因为派生值不同。我们的个人经验是，即使在集成测试期间，DI 也是有益的。尽管集成测试通常与真实的外部系统（如数据库）通信，但您仍然需要一定程度的隔离。换句话说，仍然有理由替换、拦截或模拟被测应用程序中的某些依赖项。

The ability to replace intended Dependencies with test-specific replacements is a by-product of loose coupling, but we chose to list it as a separate benefit because the derived value is different. Our personal experience is that DI is beneficial even during integration testing. Although integration tests typically communicate with real external systems (like a database), you still need to have a certain degree of isolation. In other words, there are still reasons to replace, Intercept, or mock certain Dependencies in the application being tested.

根据您正在开发的应用程序类型，您可能关心也可能不关心后期绑定的能力，但我们始终关心可测试性。一些开发人员不关心可测试性，但发现后期绑定对他们正在开发的应用程序很重要。无论如何，DI 以最小的额外开销提供了未来的选择。

Depending on the type of application you’re developing, you may or may not care about the ability to do late binding, but we always care about Testability. Some developers don’t care about Testability but find late binding important for the application they’re developing. Regardless, DI provides options in the future with minimal additional overhead today.

示例：单元测试 HelloDI 逻辑

Example: unit testing HelloDI logic

在 1.2.1 节中，您看到了 Hello DI！例子。虽然我们首先向您展示了最终代码，但我们是使用 TDD 开发的。清单 1.4显示了最重要的单元测试。

In section 1.2.1, you saw the Hello DI! example. Although we showed you the final code first, we developed it using TDD. Listing 1.4 shows the most important unit test.

清单 1.4 单元测试Salutation班级_

Listing 1.4 Unit testing the Salutation class

[Fact]
public void ExclaimWillWriteCorrectMessageToMessageWriter()
{
    var writer = new SpyMessageWriter();
    var sut = new Salutation(writer);    ①  
    sut.Exclaim();
    Assert.Equal(
        expected: "Hello DI!",
        actual: writer.WrittenMessage);
}

public class SpyMessageWriter : IMessageWriter
{
    public string WrittenMessage { get; private set; }

    public void Write(string message)
    {
        this.WrittenMessage += message;
    }
}

该类Salutation需要一个接口实例IMessageWriter，因此您需要创建一个。您可以使用任何实现，但在单元测试中，Test Double 可能很有用——在这种情况下，您可以使用自己的 Test Spy 实现。¹⁴ 

The Salutation class needs an instance of the IMessageWriter interface, so you need to create one. You could use any implementation, but in unit tests, a Test Double can be useful — in this case, you roll your own Test Spy implementation.¹⁴ 

在这种情况下，测试替身与生产实施一样复杂。这是我们的示例多么简单的产物。在大多数应用程序中，测试替身比它所代表的具体的生产实现要简单得多。重要的部分是提供特定于测试的实现，IMessageWriter以确保您一次只测试一件事。现在，您正在测试该Exclaim方法Salutation班级的，因此您不希望 的生产实施IMessageWriter污染测试。要创建该类，请传入使用构造函数注入Salutation的 Test Spy 实例IMessageWriter.

In this case, the Test Double is as involved as the production implementation. This is an artifact of how simple our example is. In most applications, a Test Double is significantly simpler than the concrete, production implementations it stands in for. The important part is to supply a test-specific implementation of IMessageWriter to ensure that you test only one thing at a time. Right now, you’re testing the Exclaim method of the Salutation class, so you don’t want a production implementation of IMessageWriter to pollute the test. To create the Salutation class, you pass in the Test Spy instance of IMessageWriter using Constructor Injection.

行使 SUT 后，您可以调用以验证预期结果是否等于实际结果。如果方法Assert.EqualIMessageWriter.Write被调用了“Hello DI!” 字符串，会把它存储在它的属性中SpyMessageWriterWrittenMessage，Equal方法完成。但是，如果该Write方法未被调用，或以不同的值被调用，则该Equal方法会抛出异常，测试会失败。

After exercising the SUT, you can call Assert.Equal to verify whether the expected outcome equals the actual outcome. If the IMessageWriter.Write method was invoked with the "Hello DI!" string, SpyMessageWriter would have stored this in its WrittenMessage property, and the Equal method completes. But if the Write method wasn’t called, or was called with a different value, the Equal method would throw an exception, and the test would fail.

松散耦合提供了许多好处：代码变得更易于开发、维护和扩展，并且变得更易于测试。这甚至不是特别困难。我们针对接口而不是具体实现进行编程。唯一的主要障碍是弄清楚如何获得这些接口的实例。DI 通过从外部注入依赖项来克服这个障碍。构造函数注入是实现这一点的首选方法，尽管我们还将在第 4 章中探索一些额外的选项。

Loose coupling provides many benefits: code becomes easier to develop, maintain, and extend, and it becomes more Testable. It’s not even particularly difficult. We program against interfaces, not concrete implementations. The only major obstacle is to figure out how to get hold of instances of those interfaces. DI surmounts this obstacle by injecting the Dependencies from the outside. Constructor Injection is the preferred method of doing that, though we’ll also explore a few additional options in chapter 4.

1.3 注入什么和不注入什么

1.3 What to inject and what not to inject

在上一节中，我们首先描述了让人想到 DI 的动机。如果您确信松散耦合是一种好处，那么您可能希望使所有内容都松散耦合。总的来说，这是个好主意。当您需要决定如何打包模块时，松散耦合被证明特别有用。但是您不必将所有内容都抽象出来并使其可插入。在本节中，我们将提供一些决策工具来帮助您决定如何对依赖项建模。

In the previous section, we described the motivational forces that makes one think about DI in the first place. If you’re convinced that loose coupling is a benefit, you may want to make everything loosely coupled. Overall, that’s a good idea. When you need to decide how to package modules, loose coupling proves especially useful. But you don’t have to abstract everything away and make it pluggable. In this section, we’ll provide some decision tools to help you decide how to model your Dependencies.

.NET BCL 由许多程序集组成。每次编写使用 BCL 程序集类型的代码时，都会向模块添加依赖项。在上一节中，我们讨论了松散耦合的重要性以及接口编程的基石。这是否意味着您不能引用任何 BCL 程序集并直接在您的应用程序中使用它们的类型？如果您想使用在 System.Xml 程序集中定义的XmlWriter？

The .NET BCL consists of many assemblies. Every time you write code that uses a type from a BCL assembly, you add a dependency to your module. In the previous section, we discussed how loose coupling is important and how programming to an interface is the cornerstone. Does this imply that you can’t reference any BCL assemblies and use their types directly in your application? What if you’d like to use an XmlWriter that’s defined in the System.Xml assembly?

您不必平等对待所有依赖项。BCL 中的许多类型都可以在不损害应用程序耦合度的情况下使用——但不是全部。重要的是要知道如何区分不会造成危险的类型和可能会加强应用程序耦合度的类型。主要关注后者。

You don’t have to treat all Dependencies equally. Many types in the BCL can be used without jeopardizing an application’s degree of coupling — but not all of them. It’s important to know how to distinguish between types that pose no danger and types that may tighten an application’s degree of coupling. Focus mainly on the latter.

在学习 DI 时，将依赖项分类为稳定依赖项和易变依赖项会很有帮助。决定将接缝放在哪里将很快成为您的第二天性。下一节将更详细地讨论这些概念。

As you learn DI, it can be helpful to categorize your Dependencies into Stable Dependencies and Volatile Dependencies. Deciding where to put your Seams will soon become second nature to you. The next sections discuss these concepts in more detail.

1.3.1 稳定的依赖

1.3.1 Stable Dependencies

BCL 中的许多模块及以上不会对应用程序的模块化程度构成威胁。它们包含可重用的功能，您可以使用这些功能使自己的代码更加简洁。BCL 模块对您的应用程序始终可用，因为它需要 .NET Framework 才能运行，并且因为它们已经存在，所以对并行开发的关注不适用于这些模块。您始终可以在另一个应用程序中重用 BCL 库。

Many of the modules in the BCL and beyond pose no threat to an application’s degree of modularity. They contain reusable functionality that you can use to make your own code more succinct. The BCL modules are always available to your application, because it needs the .NET Framework to run, and, because they already exist, the concern about parallel development doesn’t apply to these modules. You can always reuse a BCL library in another application.

默认情况下，您可以将 BCL 中定义的大多数（但不是全部）类型视为安全或稳定的依赖项。我们称它们为稳定的，因为它们已经存在，它们往往是向后兼容的，并且调用它们具有确定性的结果。大多数稳定依赖项都是 BCL 类型，但其他依赖项也可以是稳定的。稳定依赖关系的重要标准包括以下内容：

By default, you can consider most (but not all) types defined in the BCL as safe, or Stable Dependencies. We call them stable because they’re already there, they tend to be backward compatible, and invoking them has deterministic outcomes. Most Stable Dependencies are BCL types, but other Dependencies can be stable too. The important criteria for Stable Dependencies include the following:

• 类或模块已经存在。
• The class or module already exists.
• 您希望新版本不会包含重大更改。
• You expect that new versions won’t contain breaking changes.
• 所讨论的类型包含确定性算法。
• The types in question contain deterministic algorithms.
• 您永远不会期望必须用另一个替换、包装、装饰或拦截类或模块。
• You never expect to have to replace, wrap, decorate, or Intercept the class or module with another.

其他示例可能包括封装与您的应用程序相关的算法的专用库。例如，如果您正在开发处理化学的应用程序，您可以引用包含化学特定功能的第三方库。

Other examples may include specialized libraries that encapsulate algorithms relevant to your application. For example, if you’re developing an application that deals with chemistry, you can reference a third-party library that contains chemistry-specific functionality.

一般来说，Dependencies可以被认为是稳定的。如果它们不不稳定，它们就是稳定的。

In general, Dependencies can be considered stable by exclusion. They’re stable if they aren’t volatile.

1.3.2 不稳定的依赖

1.3.2 Volatile Dependencies

将Seams引入应用程序是一项额外的工作，因此您应该只在必要时才这样做。可能有不止一个原因需要隔离Seam后面的依赖关系，但这些原因与松散耦合的好处密切相关（在第 1.2.1 节中讨论）。

Introducing Seams into an application is extra work, so you should only do it when it’s necessary. There can be more than one reason it’s necessary to isolate a Dependency behind a Seam, but those reasons are closely related to the benefits of loose coupling (discussed in section 1.2.1).

这种依赖性可以通过它们干扰这些好处中的一项或多项的倾向来识别。它们不稳定，因为它们没有提供足够的应用程序的基础，因此我们称它们为易失性依赖项。如果满足以下任何条件，则应将依赖项视为易变的：

Such Dependencies can be recognized by their tendency to interfere with one or more of these benefits. They aren’t stable because they don’t provide a sufficient foundation for applications, and we call them Volatile Dependencies for that reason. A Dependency should be considered volatile if any of the following criteria are true:

• 依赖项引入了为应用程序设置和配置运行时环境的要求。易变的与其说是具体的 .NET 类型，不如说是它们对运行时环境的暗示。

  数据库是 BCL 类型的很好的例子，它们是Volatile Dependencies，而关系数据库是典型的例子。如果你不在Seam背后隐藏一个关系数据库，你就永远无法用任何其他技术取代它。它还使设置和运行自动化单元测试变得困难。（尽管 Microsoft SQL Server 客户端库是 BCL 中包含的一项技术，但它的使用暗示了关系数据库。）其他进程外资源，如消息队列、Web 服务，甚至文件系统都属于这一类。这种类型的依赖的症状是缺乏后期绑定和可扩展性，以及禁用的可测试性。

• The Dependency introduces a requirement to set up and configure a runtime environment for the application. It isn’t so much the concrete .NET types that are volatile, but rather what they imply about the runtime environment.

  Databases are good examples of BCL types that are Volatile Dependencies, and relational databases are the archetypical example. If you don’t hide a relational database behind a Seam, you can never replace it by any other technology. It also makes it hard to set up and run automated unit tests. (Even though the Microsoft SQL Server client library is a technology contained in the BCL, its usage implies a relational database.) Other out-of-process resources like message queues, web services, and even the filesystem fall into this category. The symptoms of this type of Dependency are lack of late binding and extensibility, as well as disabled Testability.

• 该依赖项尚不存在，或者仍在开发中。
• The Dependency doesn’t yet exist, or is still in development.
• 依赖项并未安装在开发组织的所有计算机上。对于无法在所有操作系统上安装的昂贵的第三方库或依赖项，可能就是这种情况。最常见的症状是禁用可测试性。
• The Dependency isn’t installed on all machines in the development organization. This may be the case for expensive third-party libraries or Dependencies that can’t be installed on all operating systems. The most common symptom is disabled Testability.
• Dependency包含不确定的行为。这在单元测试中尤为重要，因为所有测试都必须是确定性的。不确定性的典型来源是随机数和依赖于当前日期或时间的算法。

  因为 BCL 定义了不确定性的常见来源，例如、或，所以您无法避免引用定义它们的程序集。尽管如此，您应该将它们视为易失性依赖项，因为它们往往会破坏可测试性。System.RandomSystem.Security.Cryptography.RandomNumberGeneratorSystem.DateTime.Now

• The Dependency contains nondeterministic behavior. This is particularly important in unit tests because all tests must be deterministic. Typical sources of nondeterminism are random numbers and algorithms that depend on the current date or time.

  Because the BCL defines common sources of nondeterminism, such as System.Random, System.Security.Cryptography.RandomNumberGenerator, or System.DateTime.Now, you can’t avoid having a reference to the assembly in which they’re defined. Nevertheless, you should treat them as Volatile Dependencies because they tend to destroy Testability.

现在您了解了稳定依赖项和可变依赖项之间的区别，您可以开始了解 DI 范围的轮廓。松散耦合是一种普遍的设计原则，因此 DI（作为推动者）应该在您的代码库中无处不在。DI 的主题和良好的软件设计之间没有严格的界限，但是为了定义本书其余部分的范围，我们将快速描述它所涵盖的内容。

Now that you understand the differences between Stable and Volatile Dependencies, you can begin to see the contours of the scope of DI. Loose coupling is a pervasive design principle, so DI (as an enabler) should be everywhere in your code base. There’s no hard line between the topic of DI and good software design, but to define the scope of the rest of the book, we’ll quickly describe what it covers.

1.4 DI范围

1.4 DI scope

正如我们之前所讨论的，DI 的一个重要元素是将各种职责分解为单独的类。我们从课堂上带走的一项责任是创建Dependencies的实例。创建Dependencies实例的任务称为Object Composition。

As we discussed before, an important element of DI is to break up various responsibilities into separate classes. One responsibility that we take away from classes is the task of creating instances of Dependencies. The task of creating instances of Dependencies is referred to as Object Composition.

我们在 Hello DI 中讨论过这个问题！例如，我们的Salutation班级被释放了创建其Dependency的责任。相反，这个责任被转移到应用程序的Main方法. UML 图再次显示在图 1.11中。

We discussed this in our Hello DI! example where our Salutation class was released of the responsibility of creating its Dependency. Instead, this responsibility was moved to the application’s Main method. The UML diagram is shown again in figure 1.11.

当一个类放弃对Dependencies的控制时，它放弃的不仅仅是选择特定实现的决定。通过这样做，我们作为开发人员可以获得一些优势。乍一看，让类交出对创建哪些对象的控制权似乎是一种劣势，但我们并没有失去这种控制权——我们只是将它移到了另一个地方。

As a class relinquishes control of Dependencies, it gives up more than the decision to select particular implementations. By doing this, we, as developers, gain some advantages. At first, it may seem like a disadvantage to let a class surrender control over which objects are created, but we don’t lose that control — we only move it to another place.

对象组合不是我们删除的唯一控制维度：类也失去了控制对象生命周期的能力。当一个Dependency实例被注入到一个类中时，消费者不知道它是什么时候创建的，也不知道它什么时候会超出范围。这对消费者来说应该是无关紧要的。让消费者忘记其依赖项的生命周期可以简化消费者。

Object Composition isn’t the only dimension of control that we remove: a class also loses the ability to control the lifetime of the object. When a Dependency instance is injected into a class, the consumer doesn’t know when it was created, or when it’ll go out of scope. This should be of no concern to the consumer. Making the consumer oblivious to the lifetime of its Dependencies simplifies the consumer.

DI 使您有机会以统一的方式管理依赖项。当消费者直接创建和设置Dependencies的实例时，每个人都可以以自己的方式进行。这可能与其他消费者的做法不一致。您没有办法集中管理依赖关系，也没有简单的方法来解决跨领域问题. 使用 DI，您可以获得拦截每个依赖实例并在它传递给消费者之前对其进行操作的能力。这提供了应用程序的可扩展性。

DI gives you an opportunity to manage Dependencies in a uniform way. When consumers directly create and set up instances of Dependencies, each may do so in its own way. This can be inconsistent with how other consumers do it. You have no way to centrally manage Dependencies and no easy way to address Cross-Cutting Concerns. With DI, you gain the ability to Intercept each Dependency instance and act on it before it’s passed to the consumer. This provides extensibility in applications.

使用 DI，您可以在拦截依赖项并控制其生命周期的同时编写应用程序。Object Composition、Interception和Lifetime Management是 DI 的三个维度。接下来，我们将简要介绍其中的每一个；本书的第 3 部分将进行更详细的处理。

With DI, you can compose applications while intercepting Dependencies and controlling their lifetimes. Object Composition, Interception, and Lifetime Management are three dimensions of DI. Next, we’ll cover each of these briefly; a more detailed treatment follows in part 3 of the book.

1.4.1 对象组合

1.4.1 Object Composition

要获得可扩展性、后期绑定和并行开发的好处，您必须能够将类组合到应用程序中。这意味着您需要通过将各个类放在一起来创建一个应用程序，就像将电器连接在一起一样。而且，与电器一样，您会希望在引入新要求时轻松地重新排列这些类别，理想情况下无需对现有类别进行更改。

To harvest the benefits of extensibility, late binding, and parallel development, you must be able to compose classes into applications. This means that you’ll want to create an application out of individual classes by putting them together, much like plugging electrical appliances together. And, as with electrical appliances, you’ll want to easily rearrange those classes when new requirements are introduced, ideally, without having to make changes to existing classes.

对象组合通常是将 DI 引入应用程序的主要动机。事实上，最初，DI 是Object Composition的同义词；这是 Martin Fowler 关于该主题的原始文章中讨论的唯一方面。¹⁶ 

Object Composition is often the primary motivation for introducing DI into an application. In fact, initially, DI was synonymous with Object Composition; it’s the only aspect discussed in Martin Fowler’s original article on the subject.¹⁶ 

您可以通过多种方式将类组合到应用程序中。当我们讨论后期绑定时，我们使用一个配置文件和一些动态对象实例化来从可用模块手动组合应用程序。我们也可以使用DI Container使用Configuration as Code。我们将在第 12 章回到这些。

You can compose classes into an application in several ways. When we discussed late binding, we used a configuration file and a bit of dynamic object instantiation to manually compose the application from the available modules. We could also have used Configuration as Code using a DI Container. We’ll return to these in chapter 12.

许多人将 DI 称为控制反转（国际奥委会）。这两个术语有时可以互换使用，但 DI 是 IoC 的一个子集。在整本书中，我们始终使用最具体的术语——DI。如果我们指的是 IoC，我们会专门提到它。

Many people refer to DI as Inversion of Control (IoC). These two terms are sometimes used interchangeably, but DI is a subset of IoC. Throughout the book, we consistently use the most specific term — DI. If we mean IoC, we refer to it specifically.

1.4.2 对象生命周期

1.4.2 Object Lifetime

放弃对其依赖项的控制的类放弃的不仅仅是选择抽象的特定实现的权力。它还放弃了控制实例何时创建以及何时超出范围的权力。

A class that has surrendered control of its Dependencies gives up more than the power to select particular implementations of an Abstraction. It also gives up the power to control when instances are created and when they go out of scope.

在 .NET 中，垃圾收集器为我们处理这些事情。消费者可以将其依赖项注入其中并根据需要使用它们。完成后，依赖项超出范围。如果没有其他类引用它们，则它们有资格进行垃圾回收。

In .NET, the garbage collector takes care of these things for us. A consumer can have its Dependencies injected into it and use them for as long as it wants. When it’s done, the Dependencies go out of scope. If no other classes reference them, they’re eligible for garbage collection.

如果两个消费者共享相同类型的Dependency怎么办？清单 1.5说明您可以选择向每个消费者注入一个单独的实例，而清单 1.6表明您可以选择在多个消费者之间共享一个实例。但从消费者的角度来看，没有区别。根据Liskov 替换原则，消费者必须平等对待给定接口的所有实例。

What if two consumers share the same type of Dependency? Listing 1.5 illustrates that you can choose to inject a separate instance into each consumer, whereas listing 1.6 shows that you can alternatively choose to share a single instance across several consumers. But from the perspective of the consumer, there’s no difference. According to the Liskov Substitution Principle, the consumer must treat all instances of a given interface equally.

清单 1.5 消费者获取自己的同类型依赖实例

Listing 1.5 Consumers getting their own instance of the same type of Dependency

IMessageWriter writer1 = new ConsoleMessageWriter();    ①  
IMessageWriter writer2 = new ConsoleMessageWriter();    ①  

var salutation = new Salutation(writer1);    ②  
var valediction = new Valediction(writer2);    ②  

清单 1.6 共享同类型依赖实例的消费者

Listing 1.6 Consumers sharing an instance of the same type of Dependency

IMessageWriter writer = new ConsoleMessageWriter();    ①  

var salutation = new Salutation(writer);    ②  
var valediction = new Valediction(writer);    ②  

因为可以共享依赖关系，所以单个消费者不可能控制其生命周期。只要托管对象可以超出范围并被垃圾收集，这就不是什么大问题。但是当Dependencies实现IDisposable接口时，事情变得更加复杂，我们将在 8.2 节中讨论。总的来说，终身管理是 DI 的一个独立维度，并且非常重要，我们将第 8 章的所有内容都放在一边。

Because Dependencies can be shared, a single consumer can’t possibly control its lifetime. As long as a managed object can go out of scope and be garbage collected, this isn’t much of an issue. But when Dependencies implement the IDisposable interface, things become much more complicated as we’ll discuss in section 8.2. As a whole, Lifetime Management is a separate dimension of DI and important enough that we’ve set aside all of chapter 8 for it.

1.4.3 拦截

1.4.3 Interception

当我们将对依赖项的控制委托给第三方时，如图 1.12所示，我们还提供了在将它们传递给使用它们的类之前修改它们的能力。

When we delegate control over Dependencies to a third party, as figure 1.12 shows, we also provide the power to modify them before we pass them on to the classes consuming them.

在你好 DI！例如，我们最初将一个实例注入到一个实例中。然后，修改示例，我们添加了一个安全功能，方法是创建一个新的，仅在用户通过身份验证时将进一步的工作委托给。这允许您维护单一职责原则ConsoleMessageWriterSalutationSecureMessageWriterConsoleMessageWriter. 这样做是可能的，因为您总是针对接口进行编程；回想一下Dependencies必须始终是Abstractions。对于 the Salutation，它不关心提供IMessageWriter的是 aConsoleMessageWriter还是 a SecureMessageWriter。SecureMessageWritercan wrapConsoleMessageWriter仍然执行实际工作。

In the Hello DI! example, we initially injected a ConsoleMessageWriter instance into a Salutation instance. Then, modifying the example, we added a security feature by creating a new SecureMessageWriter that only delegates further work to the ConsoleMessageWriter when the user is authenticated. This allows you to maintain the Single Responsibility Principle. It’s possible to do this because you always program to interfaces; recall that Dependencies must always be Abstractions. In the case of the Salutation, it doesn’t care whether the supplied IMessageWriter is a ConsoleMessageWriter or a SecureMessageWriter. The SecureMessageWriter can wrap a ConsoleMessageWriter that still performs the real work.

拦截的这种能力使我们沿着面向方面编程的道路前进(AOP)，我们将在第 10 章和第 11 章中讨论一个密切相关的主题。使用拦截和 AOP，您可以应用横切关注点例如日志记录、审计、访问控制、验证等，以一种结构良好的方式进行，让您保持关注点分离。

Such abilities of Interception move us along the path towards Aspect-Oriented Programming (AOP), a closely related topic that we’ll cover in chapters 10 and 11. With Interception and AOP, you can apply Cross-Cutting Concerns such as logging, auditing, access control, validation, and so forth in a well-structured manner that lets you maintain Separation of Concerns.

1.4.4 三维中的 DI

1.4.4 DI in three dimensions

尽管 DI 最初是一系列旨在解决对象组合问题的模式，但该术语随后扩展到还涵盖对象生命周期和拦截。今天，我们认为 DI 以一致的方式包含所有这三个方面。

Although DI started out as a series of patterns aimed at solving the problem of Object Composition, the term has subsequently expanded to also cover Object Lifetime and Interception. Today, we think of DI as encompassing all three in a consistent way.

Object Composition往往会占据主导地位，因为如果没有灵活的Object Composition，就没有Interception也不需要管理Object Lifetime。对象组合主导了本章的大部分内容，并将继续主导本书，但你不应该忘记其他方面。对象组合提供了基础，生命周期管理解决了一些重要的副作用。但主要是当涉及到拦截时，您才开始收获好处。

Object Composition tends to dominate the picture because, without flexible Object Composition, there’d be no Interception and no need to manage Object Lifetime. Object Composition has dominated most of this chapter and will continue to dominate this book, but you shouldn’t forget the other aspects. Object Composition provides the foundation, and Lifetime Management addresses some important side effects. But it’s mainly when it comes to Interception that you start to reap the benefits.

在第 3 部分中，我们用一章专门介绍了这里简要提到的每个维度。但重要的是要知道，在实践中，DI 不仅仅是Object Composition。

In part 3, we’ve devoted a chapter to each dimension briefly mentioned here. But it’s important to know that, in practice, DI is more than Object Composition.

1.5 结论

1.5 Conclusion

依赖注入是达到目的的手段，而不是目标本身。这是实现松耦合的最佳方式，松耦合是可维护代码的重要组成部分。从松散耦合中获得的好处并不总是立即显现出来，但随着代码库复杂性的增加，它们会随着时间的推移变得明显。与 DI 相关的松散耦合的一个重点是，为了有效，它应该在代码库中无处不在。

Dependency Injection is a means to an end, not a goal in itself. It’s the best way to enable loose coupling, an important part of maintainable code. The benefits you can reap from loose coupling aren’t always immediately apparent, but they’ll become visible over time, as the complexity of a code base grows. An important point about loose coupling in relation to DI is that, in order to be effective, it should be everywhere in your code base.

紧密耦合的代码库最终会退化为意大利面条代码；¹⁸  而设计良好、松散耦合的代码库可以保持可维护性。实现真正灵活的设计需要的不仅仅是松散耦合，¹⁹  但接口编程是先决条件。

A tightly coupled code base will eventually deteriorate into Spaghetti Code;¹⁸  whereas a well-designed, loosely coupled code base can stay maintainable. It takes more than loose coupling to reach a truly supple design,¹⁹  but programming to interfaces is a prerequisite.

DI 只不过是设计原则和模式的集合。它更多地是关于一种思考和设计代码的方式，而不是关于工具和技术。DI 的目的是使代码可维护。小型代码库，如经典的 Hello World 示例，由于其大小而具有内在的可维护性。这就是为什么 DI 在简单的例子中往往看起来像过度工程。代码库越大，好处就越明显。我们在接下来的两章中专门介绍了一个更大、更复杂的示例来展示这些好处。

DI is nothing more than a collection of design principles and patterns. It’s more about a way of thinking and designing code than it is about tools and techniques. The purpose of DI is to make code maintainable. Small code bases, like a classic Hello World example, are inherently maintainable because of their size. This is why DI tends to look like overengineering in simple examples. The larger the code base becomes, the more visible the benefits. We’ve dedicated the next two chapters to a larger and more complex example to showcase these benefits.

概括

Summary

• 依赖注入是一组软件设计原则和模式，使您能够开发松散耦合的代码。松散耦合使代码更易于维护。
• Dependency Injection is a set of software design principles and patterns that enables you to develop loosely coupled code. Loose coupling makes code more maintainable.
• 当您拥有松散耦合的基础架构时，任何人都可以使用它并适应不断变化的需求和意外需求，而无需对应用程序的代码库及其基础架构进行大量更改。
• When you have a loosely coupled infrastructure in place, it can be used by anyone and adapted to changing needs and unanticipated requirements without having to make large changes to the application’s code base and its infrastructure.
• 故障排除往往会变得不那么费力，因为可能的罪魁祸首的范围缩小了。
• Troubleshooting tends to become less taxing because the scope of likely culprits narrows.
• DI 支持后期绑定，即无需重新编译原始代码即可将类或模块替换为不同类或模块的能力。
• DI enables late binding, which is the ability to replace classes or modules with different ones without the need for the original code to be recompiled.
• DI 使代码更容易以未明确计划的方式扩展和重用，类似于您在使用电插头和插座时具有灵活性的方式。
• DI makes it easier for code to be extended and reused in ways not explicitly planned for, similar to the way you have flexibility when working with electrical plugs and sockets.
• DI简化了同一代码库的并行开发，因为关注点分离允许每个团队成员甚至整个团队更轻松地处理孤立的部分。
• DI simplifies parallel development on the same code base because the Separation of Concerns allows each team member or even entire teams to work more easily on isolated parts.
• DI 使软件更易于测试，因为您可以在编写单元测试时将依赖项替换为测试实现。
• DI makes software more Testable because you can replace Dependencies with test implementations when writing unit tests.
• 当你练习 DI 时，协作类应该依赖基础设施来提供必要的服务。你可以通过让你的类依赖于接口而不是具体的实现来做到这一点。
• When you practice DI, collaborating classes should rely on infrastructure to provide the necessary services. You do this by letting your classes depend on interfaces, instead of concrete implementations.
• 类不应该向第三方询问它们的Dependencies。这是一种称为服务定位器的反模式。相反，类应该使用构造函数参数静态指定它们所需的依赖项，这种做法称为构造函数注入。
• Classes shouldn’t ask a third party for their Dependencies. This is an anti-pattern called Service Locator. Instead, classes should specify their required Dependencies statically using constructor parameters, a practice called Constructor Injection.
• 许多开发人员认为 DI 需要专门的工具，即所谓的DI 容器。这是一个神话。DI 容器是一个有用但可选的工具。
• Many developers think that DI requires specialized tooling, a so-called DI Container. This is a myth. A DI Container is a useful, but optional, tool.
• 支持 DI 的最重要的软件设计原则之一是Liskov 替换原则。它允许在不破坏客户端或实现的情况下将接口的一种实现替换为另一种实现。
• One of the most important software design principles that enables DI is the Liskov Substitution Principle. It allows replacing one implementation of an interface with another without breaking either the client or the implementation.
• 如果依赖项已经可用、具有确定性行为、不需要设置运行时环境（例如关系数据库）并且不需要被替换、包装或拦截，则它们被认为是稳定的。
• Dependencies are considered Stable in the case that they’re already available, have deterministic behavior, don’t require a setup runtime environment (such as a relational database), and don’t need to be replaced, wrapped, or intercepted.
• 依赖项在开发过程中被认为是易变的，并不总是在所有开发机器上可用，包含不确定的行为，或者需要被替换、包装或拦截。
• Dependencies are considered Volatile when they are under development, aren’t always available on all development machines, contain nondeterministic behavior, or need to be replaced, wrapped, or intercepted.
• 易失性依赖项是 DI 的焦点。我们将Volatile Dependencies注入到类的构造函数中。
• Volatile Dependencies are the focal point of DI. We inject Volatile Dependencies into a class’s constructor.
• 通过从消费者那里移除对依赖项的控制，并将该控制权移至应用程序入口点，您可以获得更轻松地应用横切关注点的能力，并且可以更有效地管理依赖项的生命周期。
• By removing control over Dependencies from their consumers, and moving that control into the application entry point, you gain the ability to apply Cross-Cutting Concerns more easily and can manage the lifetime of Dependencies more effectively.
• 要取得成功，您需要普遍应用 DI。所有类都应该使用Constructor Injection获得所需的Volatile Dependencies。很难将松散耦合和 DI 改造到现有代码库中。
• To succeed, you need to apply DI pervasively. All classes should get their required Volatile Dependencies using Constructor Injection. It’s hard to retrofit loose coupling and DI onto an existing code base.

在这一章当中

In this chapter

• 编写紧密耦合的应用程序
• Writing a tightly coupled application
• 评估该应用程序的可组合性
• Evaluating the composability of that application
• 分析该应用程序中缺乏可组合性
• Analyzing the lack of composability in that application

正如我们在第 1 章中提到的，蛋黄酱是一种由蛋黄和黄油制成的乳化酱汁，但这并不能神奇地让你具备制作蛋黄酱的能力。最好的学习方法是实践，但一个例子往往可以弥合理论与实践之间的差距。在您自己尝试之前，先观看专业厨师制作蛋黄酱酱会很有帮助。

As we mentioned in chapter 1, a sauce béarnaise is an emulsified sauce made from egg yolk and butter, but this doesn’t magically instill in you the ability to make one. The best way to learn is to practice, but an example can often bridge the gap between theory and practice. Watching a professional cook making a sauce béarnaise is helpful before you try it out yourself.

当我们在上一章介绍依赖注入 (DI) 时，我们提供了一个高级导览来帮助您理解它的目的和一般原则。但这个简单的解释并不能公正地对待 DI。DI 是一种启用松耦合的方法，而松耦合首先是一种处理复杂性的有效方法。

When we introduced Dependency Injection (DI) in the last chapter, we presented a high-level tour to help you understand its purpose and general principles. But that simple explanation doesn’t do justice to DI. DI is a way to enable loose coupling, and loose coupling is first and foremost an efficient way to deal with complexity.

大多数软件都是复杂的，因为它必须同时解决许多问题。除了本身可能很复杂的业务问题外，软件还必须解决与安全、诊断、操作、性能和可扩展性相关的问题。松耦合鼓励您单独解决每个问题，而不是在一个大泥球中解决所有这些问题。单独解决每个问题更容易，但最终，您仍然必须将这组复杂的问题组合到一个应用程序中。

Most software is complex in the sense that it must address many issues simultaneously. Besides the business concerns, which may be complex in their own right, software must also address matters related to security, diagnostics, operations, performance, and extensibility. Instead of addressing all of these concerns in one big ball of mud, loose coupling encourages you to address each concern separately. It’s easier to address each in isolation, but ultimately, you must still compose this complex set of issues into a single application.

在本章中，我们将看一个更复杂的例子。您将看到编写紧密耦合的代码是多么容易。您还将与我们一起从可维护性的角度分析为什么紧密耦合的代码会出现问题。在第 3 章中，我们将使用 DI 将这一紧耦合的代码库完全重写为松耦合的代码库。如果你想马上看到松散耦合的代码，你可能想跳过这一章。如果没有，当你读完本章后，你应该开始理解是什么导致紧耦合代码如此成问题。

In this chapter, we’ll take a look at a more complex example. You’ll see how easy it is to write tightly coupled code. You’ll also join us in an analysis of why tightly coupled code is problematic from a maintainability perspective. In chapter 3, we’ll use DI to completely rewrite this tightly coupled code base to one that’s loosely coupled. If you want to see loosely coupled code right away, you may want to skip this chapter. If not, when you’re done with this chapter, you should begin to understand what it is that makes tightly coupled code so problematic.

2.1 构建紧耦合应用

2.1 Building a tightly coupled application

构建松散耦合代码的想法并不是特别有争议，但理论与实践之间存在巨大差距。在下一章向您展示如何使用 DI 构建松散耦合的应用程序之前，我们想向您展示它是多么容易出错。松散耦合代码的常见尝试是构建分层应用程序。任何人都可以画出三层应用图，图2.1证明我们也可以。

The idea of building loosely coupled code isn’t particularly controversial, but there’s a huge gap between theory and practice. Before we show you in the next chapter how to use DI to build a loosely coupled application, we want to show you how easily it can go wrong. A common attempt at loosely coupled code is building a layered application. Anyone can draw a three-layer application diagram, and figure 2.1 proves that we can too.

绘制三层图看似简单，但绘制图表的行为类似于声明您将在牛排中加入蛋黄酱：这是一种意图声明，不保证最终结果。你很快就会看到，你可以得到别的东西。

Drawing a three-layer diagram is deceptively simple, but the act of drawing the diagram is akin to stating that you’ll have sauce béarnaise with your steak: it’s a declaration of intent that carries no guarantee with regard to the final result. You can end up with something else, as you shall soon see.

查看和设计灵活且可维护的复杂应用程序的方法不止一种，但是n层应用程序架构构成了一种众所周知的、久经考验的方法。挑战在于正确实施它。有了如图 2.1 所示的三层图，您就可以开始构建应用程序了。

There’s more than one way to view and design a flexible and maintainable complex application, but the n-layer application architecture constitutes a well-known, tried-and-tested approach. The challenge is to implement it correctly. Armed with a three-layer diagram like the one in figure 2.1, you can start building an application.

2.1.1 认识玛丽罗文

2.1.1 Meet Mary Rowan

Mary Rowan 是一名专业的 .NET 开发人员，就职于一家主要开发 Web 应用程序的本地 Microsoft 认证合作伙伴。她今年 34 岁，从事软件工作已有 11 年。这使她成为更有经验的开发人员之一在公司里。除了履行作为高级开发人员的常规职责外，她还经常担任初级开发人员的导师。总的来说，Mary 对她所做的工作很满意，但令她感到沮丧的是，里程碑经常被错过，这迫使她和她的同事长时间工作并在周末工作以赶上最后期限。

Mary Rowan is a professional .NET developer working for a local Certified Microsoft Partner that mainly develops web applications. She’s 34 years old and has been working with software for 11 years. This makes her one of the more experienced developers in the company. In addition to performing her regular duties as a senior developer, she often acts as a mentor for junior developers. In general, Mary is happy about the work that she’s doing, but it frustrates her that milestones are often missed, forcing her and her colleagues to work long hours and weekends to meet deadlines.

她怀疑必须有更有效的方法来构建软件。为了学习效率，她买了很多编程书籍，但很少有时间阅读，因为她的大部分业余时间都花在了丈夫和两个女儿身上。玛丽喜欢去山里远足。她也是一位热心的厨师，她绝对知道如何制作真正的贝恩酱酱。

She suspects that there must be more efficient ways to build software. In an effort to learn about efficiency, she buys a lot of programming books, but she rarely has time to read them, as much of her spare time is spent with her husband and two girls. Mary likes to go hiking in the mountains. She’s also an enthusiastic cook, and she definitely knows how to make a real sauce béarnaise.

Mary 被要求在 ASP.NET Core MVC 和 Entity Framework Core 上创建一个新的电子商务应用程序，并将 SQL Server 作为数据存储。为了最大化模块化，它必须是一个三层应用程序。

Mary has been asked to create a new e-commerce application on ASP.NET Core MVC and Entity Framework Core with SQL Server as the data store. To maximize modularity, it must be a three-layer application.

要实现的第一个功能应该是一个简单的特色产品列表，从数据库表中提取并显示在网页上（示例如图 2.2所示）。并且，如果查看列表的用户是优先客户，则所有产品的价格都应有 5% 的折扣。

The first feature to implement should be a simple list of featured products, pulled from a database table and displayed on a web page (an example is shown in figure 2.2). And, if the user viewing the list is a preferred customer, the price on all products should be discounted by 5%.

为了完成她的第一个功能，Mary 必须执行以下操作：

To complete her first feature, Mary will have to implement the following:

• 数据层— 在数据库中包含一个 Products 表，它表示所有数据库行，以及一个Product类，它表示单个数据库行
• A data layer — Includes a Products table in the database, which represents all database rows, and a Product class, which represents a single database row
• 领域层— 包含检索特色产品的逻辑
• A domain layer — Contains the logic for retrieving the featured products
• 用户界面层使用 MVC 控制器- 处理传入请求，从域层检索相关数据，并将其发送到 Razor 视图，最终呈现特色产品列表
• A UI Layer with an MVC controller — Handles incoming requests, retrieves the relevant data from the domain layer, and sends it to the Razor view, which eventually renders the list of featured products

让我们看看 Mary 在实现应用程序的第一个功能时的工作。

Let’s look over Mary’s shoulder as she implements the application’s first feature.

2.1.2 创建数据层

2.1.2 Creating the data layer

因为 Mary 需要从数据库表中提取数据，所以她决定从实现数据层开始。第一步是定义数据库表本身。Mary 使用 SQL Server Management Studio 创建表 2.1中所示的表。

Because Mary will need to pull data from a database table, she has decided to begin by implementing the data layer. The first step is to define the database table itself. Mary uses SQL Server Management Studio to create the table shown in table 2.1.

为了实现数据访问层，Mary 在她的解决方案中添加了一个新库。以下清单显示了她的Product班级.

To implement the data access layer, Mary adds a new library to her solution. The following listing shows her Product class.

清单 2.1 玛丽的Product班级

Listing 2.1 Mary’s Product class

public class Product
{
    public Guid Id { get; set; }
    public string Name { get; set; }
    public string Description { get; set; }
    public decimal UnitPrice { get; set; }
    public bool IsFeatured { get; set; }
}

Mary 使用 Entity Framework 来满足她的数据访问需求。她将 Microsoft.EntityFrameworkCore.SqlServer NuGet 包的依赖项添加到她的项目中，并实现了一个特定于应用程序的DbContext类允许她的应用程序通过CommerceContext类访问 Products 表. 以下清单显示了她的CommerceContext班级。

Mary uses Entity Framework for her data access needs. She adds a dependency to the Microsoft.EntityFrameworkCore.SqlServer NuGet package to her project, and implements an application-specific DbContext class that allows her application to access the Products table via the CommerceContext class. The following listing shows her CommerceContext class.

清单 2.2 Mary 的CommerceContext班级

Listing 2.2 Mary’s CommerceContext class

public class CommerceContext : Microsoft.EntityFrameworkCore.DbContext
{
    public DbSet<Product> Products { get; set; }    ①  

    protected override void OnConfiguring(    ②  
        DbContextOptionsBuilder builder)
    {
        var config = new ConfigurationBuilder()    ③  
            .SetBasePath(    ③  
                Directory.GetCurrentDirectory())    ③  
            .AddJsonFile("appsettings.json")    ③  
            .Build();    ③  

        string connectionString =    ④  
            config.GetConnectionString(    ④  
                "CommerceConnectionString");    ④  
    ④  
        builder.UseSqlServer(connectionString);    ④  
    }
}

因为从配置文件加载连接字符串，所以需要创建该文件。Mary 将一个名为 appsettings.json 的文件添加到她的 Web 项目中，其中包含以下内容：CommerceContext

Because CommerceContext loads a connection string from a configuration file, that file needs to be created. Mary adds a file named appsettings.json to her web project, with the following content:

{
  "ConnectionStrings": {
    "CommerceConnectionString":
      "Server=.;Database=MaryCommerce;Trusted_Connection=True;"
  }
}

CommerceContext并且Product是包含在同一程序集中的公共类型。Mary 知道她稍后需要向她的应用程序添加更多功能，但是实现第一个功能所需的数据访问组件现在已经完成（图 2.3）。

CommerceContext and Product are public types contained within the same assembly. Mary knows that she’ll later need to add more features to her application, but the data access component required to implement the first feature is now completed (figure 2.3).

现在已经实现了数据访问层，下一个合乎逻辑的步骤是域层。领域层也称为领域逻辑层、业务层或业务逻辑层。域逻辑是应用程序需要具有的所有行为，特定于应用程序的构建域。

Now that the data access layer has been implemented, the next logical step is the domain layer. The domain layer is also referred to as the domain logic layer, business layer, or business logic layer. Domain logic is all the behavior that the application needs to have, specific to the domain the application is built for.

2.1.3 创建领域层

2.1.3 Creating the domain layer

除了纯数据报告应用程序之外，始终存在域逻辑。一开始您可能没有意识到，但随着您对领域的了解，其内嵌和隐含的规则和假设将逐渐浮出水面。在没有任何域逻辑的情况下，CommerceContext从技术上讲，可以直接从 UI 层使用所公开的产品列表。

With the exception of pure data-reporting applications, there’s always domain logic. You may not realize it at first, but as you get to know the domain, its embedded and implicit rules and assumptions will gradually emerge. In the absence of any domain logic, the list of products exposed by CommerceContext could technically have been used directly from the UI layer.

Mary 的应用程序要求向优先客户显示产品标价和 5% 的折扣。Mary 还没有弄清楚如何确定首选客户，因此她向她的同事 Jens 寻求建议：

The requirements for Mary’s application state that preferred customers should be shown the product list prices with a 5% discount. Mary has yet to figure out how to identify a preferred customer, so she asks her coworker Jens for advice:

玛丽：我需要实施这个业务逻辑，以便优先客户获得 5% 的折扣。

Mary: I need to implement this business logic so that a preferred customer gets a 5% discount.

延斯：听起来很简单。只需乘以 0.95。

Jens: Sounds easy. Just multiply by .95.

玛丽：谢谢，但这不是我想问你的。我想问你的是，我应该如何识别一个优先客户？

Mary: Thanks, but that’s not what I wanted to ask you about. What I wanted to ask you is, how should I identify a preferred customer?

詹斯：我明白了。这是 Web 应用程序还是桌面应用程序？

Jens: I see. Is this a web application or a desktop application?

玛丽：这是一个网络应用程序。

Mary: It’s a web app.

Jens：好的，那么你可以使用该User属性的HttpContext检查当前用户是否在角色中PreferredCustomer。

Jens: Okay, then you can use the User property of the HttpContext to check if the current user is in the role PreferredCustomer.

玛丽：慢点，延斯。此代码必须在域层中。这是一个图书馆。没有HttpContext.

Mary: Slow down, Jens. This code must be in the domain layer. It’s a library. There’s no HttpContext.

詹斯：哦。[想了想]我仍然认为你应该使用HttpContextASP.NET 来为用户查找值。然后您可以将该值作为布尔值传递给您的域逻辑。

Jens: Oh. [Thinks for a while] I still think you should use the HttpContext of ASP.NET to look up the value for the user. You can then pass the value to your domain logic as a boolean.

玛丽：我不知道……

Mary: I don’t know...

Jens：这也将确保您有良好的关注点分离，因为您的领域逻辑不必处理安全问题。你知道，单一职责原则！这是做到这一点的敏捷方法！

Jens: That’ll also ensure that you have good Separation of Concerns because your domain logic doesn’t have to deal with security. You know, the Single Responsibility Principle! It’s the Agile way to do it!

玛丽：我想你说得有道理。

Mary: I guess you’ve got a point.

Jens 的建议基于他对 ASP.NET 的技术知识。当讨论把他带离自己的舒适区时，他用流行语的三重组合来压制玛丽。请注意，Jens 并不知道他在说什么：

Jens is basing his advice on his technical knowledge of ASP.NET. As the discussion takes him away from his comfort zone, he steamrolls Mary with a triple combo of buzzwords. Be aware that Jens doesn’t know what he’s talking about:

• 他滥用了关注点分离的概念. 尽管将安全问题与域逻辑分开很重要，但将其移至表示层无助于分离问题。
• He misuses the concept of Separation of Concerns. Although it’s important to separate security concerns from the domain logic, moving this to the presentation layer doesn’t help in separating concerns.
• 他之所以提到敏捷，是因为他最近听到其他人热情地谈论它。
• He only mentions Agile because he recently heard someone else talk enthusiastically about it.
• 他完全忽略了单一职责原则的要点. 尽管敏捷方法提供的快速反馈周期可以帮助您相应地改进软件设计，但作为软件设计原则的单一职责原则本身独立于所选的软件开发方法。
• He completely misses the point of the Single Responsibility Principle. Although the quick feedback cycle that Agile methodologies provide can help you improve your software design accordingly, by itself, the Single Responsibility Principle as a software design principle is independent of the chosen software development methodology.

不幸的是，有了 Jens 糟糕的建议，Mary 创建了一个新的 C# 库项目并添加了一个名为 的类，如清单 2.3所示。为了使该类编译，她必须添加对她的数据访问层的引用，因为该类是在那里定义的。ProductServiceProductServiceCommerceContext

Armed with Jens’ unfortunately poor advice, Mary creates a new C# library project and adds a class called ProductService, shown in listing 2.3. To make the ProductService class compile, she must add a reference to her data access layer, because the CommerceContext class is defined there.

清单 2.3 Mary 的ProductService班级

Listing 2.3 Mary’s ProductService class

public class ProductService
{
    private readonly CommerceContext dbContext;

    public ProductService()
    {
        this.dbContext = new CommerceContext();    ①  
    }

    public IEnumerable<Product> GetFeaturedProducts(
        bool isCustomerPreferred)
    {
        decimal discount =
            isCustomerPreferred ? .95m : 1;

        var featuredProducts =    ②  
            from product in this.dbContext.Products    ②  
            where product.IsFeatured    ②  
            select product;

        return
            from product in    ③  
                featuredProducts.AsEnumerable()    ③  
            select new Product    ③  
            {    ③  
                Id = product.Id,    ③  
                Name = product.Name,    ③  
                Description = product.Description,    ③  
                IsFeatured = product.IsFeatured,    ③  
                UnitPrice =    ③  
                    product.UnitPrice * discount    ③  
            };
    }
}

Mary 很高兴她在ProductService类中封装了数据访问技术 (Entity Framework Core)、配置和域逻辑。她通过传入isCustomerPreferred参数将用户的知识委托给了调用者，她使用此值计算所有产品的折扣。

Mary’s happy that she has encapsulated the data access technology (Entity Framework Core), configuration, and domain logic in the ProductService class. She has delegated the knowledge of the user to the caller by passing in the isCustomerPreferred parameter, and she uses this value to calculate the discount for all the products.

进一步的改进可能包括用可配置的数字替换硬编码的折扣值 (.95)，但就目前而言，这种实现就足够了。玛丽快完成了。唯一剩下的就是 UI 层。玛丽决定可以等到明天。图 2.4显示了 Mary 在实现图 2.1中设想的体系结构方面取得了多大进展。

Further refinement could include replacing the hard-coded discount value (.95) with a configurable number, but, for now, this implementation will suffice. Mary’s almost done. The only thing still left is the UI layer. Mary decides that it can wait until tomorrow. Figure 2.4 shows how far Mary has come with implementing the architecture envisioned in figure 2.1.

Mary 没有意识到的是，通过让依赖项依赖于数据访问层的类，她将她的领域层与数据访问层紧密耦合。我们将在 2.2 节中解释这有什么问题。ProductServiceCommerceContext

What Mary doesn’t realize is that by letting the ProductService depend on the data access layer’s CommerceContext class, she tightly coupled her domain layer to the data access layer. We’ll explain what’s wrong with that in section 2.2.

2.1.4 创建UI层

2.1.4 Creating the UI layer

第二天，Mary 继续使用电子商务应用程序，将新的 ASP.NET Core MVC 应用程序添加到她的解决方案中。如果您不熟悉 ASP.NET Core MVC 框架，请不要担心。MVC 框架如何运作的复杂细节不是本次讨论的重点。重要的部分是如何使用依赖项，这是一个相对平台中立的主题。

The next day, Mary resumes her work with the e-commerce application, adding a new ASP.NET Core MVC application to her solution. Don’t worry if you aren’t familiar with the ASP.NET Core MVC framework. The intricate details of how the MVC framework operates aren’t the focus of this discussion. The important part is how Dependencies are consumed, and that’s a relatively platform-neutral subject.

下一个清单显示了 Mary 如何实现一个Index方法在她的HomeController课堂上从数据库中提取特色产品并将它们传递给视图。为了使这段代码编译通过，她必须添加对数据访问层和域层的引用。这是因为ProductService类是在领域层定义的，而Product类是在数据访问层定义的。

The next listing shows how Mary implements an Index method on her HomeController class to extract the featured products from the database and pass them to the view. To make this code compile, she must add references to both the data access layer and the domain layer. This is because the ProductService class is defined in the domain layer, but the Product class is defined in the data access layer.

Index默认控制器类上的清单 2.4方法

Listing 2.4 Index method on the default controller class

public ViewResult Index()
{
    bool isPreferredCustomer =    ①  
        this.User.IsInRole("PreferredCustomer");    ①  

    var service = new ProductService();    ②  

    var products = service.GetFeaturedProducts(    ③  
        isPreferredCustomer);    ③  

    this.ViewData["Products"] = products;    ④  

    return this.View();
}

作为 ASP.NET Core MVC 生命周期的一部分，User属性类上的HomeController会自动填充正确的用户对象，因此 Mary 使用它来确定当前用户是否是首选客户。有了这些信息，她就可以调用域逻辑来获取特色产品列表。

As part of the ASP.NET Core MVC lifecycle, the User property on the HomeController class is automatically populated with the correct user object, so Mary uses it to determine if the current user is a preferred customer. Armed with this information, she can invoke the domain logic to get the list of featured products.

在 Mary 的应用程序中，产品列表必须由Index视图呈现。以下清单显示了视图的标记。

In Mary’s application, the list of products must be rendered by the Index view. The following listing shows the markup for the view.

清单 2.5 Index视图标记

Listing 2.5 Index view markup

<h2>Featured Products</h2>
<div>
@{
    var products =    ①  
        (IEnumerable<Product>)this.ViewData["Products"];    ①  

    foreach (Product product in products)    ②  
    {
        <div>@product.Name (@product.UnitPrice.ToString("C"))</div>
    }
}
</div>

ASP.NET Core MVC 允许您编写标准 HTML，其中嵌入了一些命令式代码，以访问由创建视图的控制器创建和分配的对象。在这种情况下，HomeController的Index方法将特色产品列表分配给一个名为ProductsMary 在视图中用于呈现产品列表的键。图 2.5显示了 Mary 现在如何实现图 2.1中设想的体系结构。

ASP.NET Core MVC lets you write standard HTML with bits of imperative code embedded to access objects created and assigned by the controller that created the view. In this case, the HomeController’s Index method assigned the list of featured products to a key called Products that Mary uses in the view to render the list of products. Figure 2.5 shows how Mary has now implemented the architecture envisioned in figure 2.1.

所有三层都到位后，应用程序理论上应该可以正常工作。但只有运行该应用程序，她才能验证情况是否如此。

With all three layers in place, the applications should theoretically work. But only by running the application can she verify whether that’s the case.

2.2 评估紧耦合应用

2.2 Evaluating the tightly coupled application

Mary 现在已经实现了所有三个层，所以是时候看看应用程序是否正常工作了。她按下F5，出现如图2.2所示的网页。Featured Products 功能现已完成，Mary 充满信心并准备好在应用程序中实施下一个功能。毕竟，她遵循既定的最佳实践并创建了一个三层应用程序……或者她做到了吗？

Mary has now implemented all three layers, so it’s time to see if the application works. She presses F5 and the web page shown in figure 2.2 appears. The Featured Products feature is now done, and Mary feels confident and ready to implement the next feature in the application. After all, she followed established best practices and created a three-layer application ... or did she?

Mary 是否成功开发了合适​​的分层应用程序？不，她没有，尽管她当然是出于好意。她创建了三个 Visual Studio 项目，对应于计划架构中的三个层。对于不经意的观察者来说，这看起来像是梦寐以求的分层架构，但是，正如您将看到的，代码是紧密耦合的。

Did Mary succeed in developing a proper, layered application? No, she didn’t, although she certainly had the best of intentions. She created three Visual Studio projects that correspond to the three layers in the planned architecture. To the casual observer, this looks like the coveted layered architecture, but, as you’ll see, the code is tightly coupled.

Visual Studio 使以这种方式处理解决方案和项目变得简单自然。如果您需要来自不同库的功能，您可以轻松地添加对它的引用并编写代码来创建其他库中定义的类型的新实例。但是，每次添加引用时，您都会承担一个Dependency。

Visual Studio makes it easy and natural to work with solutions and projects in this way. If you need functionality from a different library, you can easily add a reference to it and write code that creates new instances of the types defined in the other libraries. Every time you add a reference, though, you take on a Dependency.

2.2.1 评估依赖图

2.2.1 Evaluating the dependency graph

在 Visual Studio 中使用解决方案时，很容易忘记重要的依赖项。这是因为 Visual Studio 将它们与可能指向 .NET 基类库中的程序集的所有其他项目引用一起显示（BCL）。要了解 Mary 的应用程序中的模块如何相互关联，我们可以绘制依赖关系图（见图 2.6）。

When working with solutions in Visual Studio, it’s easy to lose track of the important Dependencies. This is because Visual Studio displays them together with all the other project references that may point to assemblies in the .NET Base Class Library (BCL). To understand how the modules in Mary’s application relate to each other, we can draw a graph of the dependencies (see figure 2.6).

从图 2.6中获得的最显着的洞察力是 UI 层同时依赖于域和数据访问层。在某些情况下，UI 似乎可以绕过领域层。这需要进一步调查。

The most remarkable insight to be gained from figure 2.6 is that the UI layer depends on both domain and data access layers. It seems as though the UI could bypass the domain layer in certain cases. This requires further investigation.

2.2.2 评估可组合性

2.2.2 Evaluating composability

构建三层应用程序的一个主要目标是分离关注点。我们希望将我们的域模型与数据访问层和 UI 层分开，以便这些问题都不会污染域模型。在大型应用程序中，能够独立处理应用程序的每个区域至关重要。为了评估 Mary 的实现，我们可以问一个简单的问题：是否可以单独使用每个模块？

A major goal of building a three-layer application is to separate concerns. We’d like to separate our domain model from the data access and UI layers so that none of these concerns pollute the domain model. In large applications, it’s essential to be able to work with each area of the application in isolation. To evaluate Mary’s implementation, we can ask a simple question: Is it possible to use each module in isolation?

理论上，我们应该能够以任何我们喜欢的方式组合模块。我们可能需要编写新模块以新的和意想不到的方式将现有模块绑定在一起，但理想情况下，我们应该能够这样做而不必修改现有模块。我们能否以令人兴奋的新方式使用 Mary 的应用程序中的模块？让我们看看一些可能的情况。

In theory, we should be able to compose modules any way we like. We may need to write new modules to bind existing modules together in new and unanticipated ways, but, ideally, we should be able to do so without having to modify the existing modules. Can we use the modules in Mary’s application in new and exciting ways? Let’s look at some likely scenarios.

构建新的用户界面

Building a new UI

如果 Mary 的应用程序成功，项目利益相关者希望她在 Windows Presentation Foundation (WPF). 在重用域和数据访问层时可以这样做吗？

If Mary’s application becomes a success, the project stakeholders would like her to develop a rich client version in Windows Presentation Foundation (WPF). Is this possible to do while reusing the domain and data access layers?

当我们检查图 2.6中的依赖关系图时，我们可以快速确定没有模块依赖于 Web UI，因此可以删除它并用 WPF UI 替换它。创建基于 WPF 的富客户端是一个新的应用程序，它与原始 Web 应用程序共享其大部分实现。图 2.7说明了 WPF 应用程序如何需要采用与 Web 应用程序相同的依赖项。原始 Web 应用程序可以保持不变。

When we examine the dependency graph in figure 2.6, we can quickly ascertain that no modules are depending on the web UI, so it’s possible to remove it and replace it with a WPF UI. Creating a rich client based on WPF is a new application that shares most of its implementation with the original web application. Figure 2.7 illustrates how a WPF application would need to take the same dependencies as the web application. The original web application can remain unchanged.

Mary 的实现当然可以替换 UI 层。让我们检查另一个有趣的分解。

Replacing the UI layer is certainly possible with Mary’s implementation. Let’s examine another interesting decomposition.

构建新的数据访问层

Building a new data access layer

玛丽的市场分析师发现，为了优化利润，她的应用程序应该作为托管在 Microsoft Azure 上的云应用程序提供. 在蔚蓝，数据可以存储在高度可扩展的 Azure 表存储服务中。这种存储机制基于包含不受约束数据的灵活数据容器。该服务不强制执行特定的数据库模式，也没有参照完整性。

Mary’s market analysts figure out that, to optimize profits, her application should be available as a cloud application hosted on Microsoft Azure. In Azure, data can be stored in the highly scalable Azure Table Storage Service. This storage mechanism is based on flexible data containers that contain unconstrained data. The service enforces no particular database schema, and there’s no referential integrity.

尽管 .NET 上最常见的数据访问技术是基于 ADO.NET 数据服务，用于与表存储服务通信的协议是 HTTP。这种类型的数据库有时称为键值数据库，它与通过 Entity Framework Core 访问的关系数据库不同。

Although the most common data access technology on .NET is based on ADO.NET Data Services, the protocol used to communicate with the Table Storage Service is HTTP. This type of database is sometimes known as a key-value database, and it’s a different beast than a relational database accessed through Entity Framework Core.

要使电子商务应用程序成为云应用程序，必须将数据访问层替换为使用表存储服务的模块。这可能吗？

To enable the e-commerce application as a cloud application, the data access layer must be replaced with a module that uses the Table Storage Service. Is this possible?

从图 2.6的依赖图中，我们已经知道 UI 层和领域层都依赖于基于 Entity Framework 的数据访问层。如果我们尝试删除数据访问层，解决方案将不再编译而不重构所有其他项目，因为缺少必需的依赖项。在一个有几十个模块的大型应用程序中，我们也可以尝试删除不编译的模块，看看会剩下什么。对于 Mary 的应用程序，很明显我们必须删除所有模块，不留下任何东西，如图 2.8所示。

From the dependency graph in figure 2.6, we already know that both the UI and domain layers depend on the Entity Framework–based data access layer. If we try to remove the data access layer, the solution will no longer compile without refactoring all other projects because a required Dependency is missing. In a big application with dozens of modules, we could also try to remove the modules that don’t compile to see what would be left. In the case of Mary’s application, it’s evident that we’d have to remove all modules, leaving nothing behind, as figure 2.8 shows.

尽管可以开发 Azure 表数据访问层模仿原始数据访问层公开的 API，我们无法在不触及应用程序其他部分的情况下将其应用于应用程序。该应用程序的可组合性远不如项目利益相关者所希望的那样。启用利润最大化的云功能需要对应用程序进行重大重写，因为现有模块都不能重复使用。

Although it would be possible to develop an Azure Table data access layer that mimics the API exposed by the original data access layer, there’s no way we could apply that to the application without touching other parts of the application. The application isn’t nearly as composable as the project stakeholders would have liked. Enabling the profit-maximizing cloud abilities requires a major rewrite of the application because none of the existing modules can be reused.

评估其他组合

Evaluating other combinations

我们可以分析其他模块组合的应用程序，但这将是一个有争议的问题，因为我们已经知道它无法支持一个重要的场景。此外，并非所有组合都有意义。

We could analyze the application for other combinations of modules, but this would be a moot point because we already know that it fails to support an important scenario. Besides, not all combinations make sense.

例如，我们可以询问是否有可能用不同的实现替换域模型。但是，在大多数情况下，这是一个奇怪的问题，因为域模型封装了应用程序的核心。没有领域模型，大多数应用程序就没有存在的理由。

For instance, we could ask whether it would be possible to replace the domain model with a different implementation. But, in most cases, this would be an odd question to ask because the domain model encapsulates the heart of the application. Without the domain model, most applications have no reason to exist.

2.3 缺失可组合性分析

2.3 Analysis of missing composability

为什么 Mary 的实现未能达到预期的可组合性程度？是不是因为UI直接依赖于数据访问层？让我们更详细地研究这种可能性。

Why did Mary’s implementation fail to achieve the desired degree of composability? Is it because the UI has a direct dependency on the data access layer? Let’s examine this possibility in greater detail.

2.3.1 依赖图分析

2.3.1 Dependency graph analysis

为什么UI依赖于数据访问库？罪魁祸首是这个领域模型的方法签名：

Why does the UI depend on the data access library? The culprit is this domain model’s method signature:

GetFeaturedProducts方法_ProductService班级的返回一系列产品，但Product该类是在数据访问层中定义的。任何使用该GetFeaturedProducts方法的客户端都必须引用数据访问层才能进行编译。可以更改方法的签名以返回域模型中定义的类型。它也会更正确，但它不能解决问题。

The GetFeaturedProducts method of the ProductService class returns a sequence of products, but the Product class is defined in the data access layer. Any client consuming the GetFeaturedProducts method must reference the data access layer to be able to compile. It’s possible to change the signature of the method to return a type defined within the domain model. It’d also be more correct, but it doesn’t solve the problem.

假设我们打破了 UI 和数据访问库之间的依赖关系. 修改后的依赖关系图现在如图 2.9 所示。

Let’s assume that we break the dependency between the UI and data access library. The modified dependency graph would now look like figure 2.9.

这样的更改是否能让 Mary 将关系数据访问层替换为封装对 Azure 表服务的访问的层？不幸的是，没有，因为领域层仍然依赖于数据访问层。反过来，UI 仍然依赖于域模型。如果我们试图移除原始数据访问层，应用程序将一无所有。问题的根本原因在别处。

Would such a change enable Mary to replace the relational data access layer with one that encapsulates access to the Azure Table service? Unfortunately, no, because the domain layer still depends on the data access layer. The UI, in turn, still depends on the domain model. If we try to remove the original data access layer, there’d be nothing left of the application. The root cause of the problem lies somewhere else.

2.3.2 数据访问接口分析

2.3.2 Data access interface analysis

域模型依赖于数据访问层，因为整个数据模型都在那里定义。使用实体框架来实现数据访问层可能是一个合理的决定。但是，从松散耦合的角度来看，直接在域模型中使用它并不是。

The domain model depends on the data access layer because the entire data model is defined there. Using Entity Framework to implement a data access layer may be a reasonable decision. But, from the perspective of loose coupling, consuming it directly in the domain model isn’t.

有问题的代码散布在ProductService课堂上。构造函数创建CommerceContext类的新实例并将其分配给私有成员变量：

The offending code can be found spread out in the ProductService class. The constructor creates a new instance of the CommerceContext class and assigns it to a private member variable:

this.dbContext = new CommerceContext();

ProductService这将类与数据访问层紧密耦合。没有合理的方法可以拦截这段代码并将其替换为其他代码。对数据访问层的引用被硬编码到ProductService类中！

This tightly couples the ProductService class to the data access layer. There’s no reasonable way you can Intercept this piece of code and replace it with something else. The reference to the data access layer is hard-coded into the ProductService class!

GetFeaturedProducts方法的实现用于从数据库CommerceContext中提取Product对象：

The implementation of the GetFeaturedProducts method uses CommerceContext to pull Product objects from the database:

var featuredProducts =
    from product in this.dbContext.Products
    where product.IsFeatured
    select product;

CommerceContext对within的引用GetFeaturedProducts加强了硬编码的依赖性，但此时，损害已经造成。我们需要的是一种没有这种紧密耦合的更好的模块组合方式。如果您回顾第 1 章中讨论的 DI 的好处，您会发现 Mary 的应用程序没有以下内容：

The reference to CommerceContext within GetFeaturedProducts reinforces the hard-coded dependency, but, at this point, the damage is already done. What we need is a better way to compose modules without such tight coupling. If you look back at the benefits of DI as discussed in chapter 1, you’ll see that Mary’s application fails to have the following:

• 后期绑定 — 由于域层与数据访问层紧密耦合，因此不可能部署同一应用程序的两个版本，其中一个连接到本地 SQL Server 数据库，另一个使用 Azure 表存储托管在 Microsoft Azure 上。换句话说，使用后期绑定加载正确的数据访问层是不可能的。
• Late binding — Because the domain layer is tightly coupled with the data access layer, it becomes impossible to deploy two versions of the same application, where one connects to a local SQL Server database and the other is hosted on Microsoft Azure using Azure Table Storage. In other words, it’s impossible to load the correct data access layer using late binding.
• 可扩展性 — 因为应用程序中的所有类都彼此紧密耦合，所以像第 1 章中的安全特性一样插入横切关注点的成本很高。这样做需要更改系统中的许多类。因此，这种紧密耦合的设计不是特别可扩展的。
• Extensibility — Because all classes in the application are tightly coupled to one another, it becomes costly to plug in Cross-Cutting Concerns like the security feature in chapter 1. Doing so requires many classes in the system to be changed. This tightly coupled design is, therefore, not particularly extensible.
• 可维护性 — 不仅会添加横切关注点需要在整个应用程序中进行彻底的更改，但是每个新添加的横切关注点都可能会使每个涉及的类更加复杂。每次添加都会使课程更难阅读。这意味着该应用程序不像 Mary 所希望的那样易于维护。
• Maintainability — Not only would adding Cross-Cutting Concerns require sweeping changes throughout the application, but every newly added Cross-Cutting Concern would likely make each class touched even more complex. Every addition would make a class harder to read. This means that the application isn’t as maintainable as Mary would like.
• 并行开发 — 如果我们坚持前面应用横切关注点的示例，就很容易理解必须对整个代码库进行全面更改会阻碍与多个开发人员在单个应用程序上并行工作的能力。像我们一样，在过去将您的工作提交到版本控制系统时，您可能已经处理过痛苦的合并冲突。一个设计良好、松散耦合的系统，除其他外，将减少您将拥有的合并冲突的数量。当更多的开发人员开始处理 Mary 的应用程序时，要在不影响彼此的情况下有效地工作会变得越来越难。
• Parallel development — If we stick with the previous example of applying Cross-Cutting Concerns, it’s quite easy to understand that having to make sweeping changes throughout your code base hinders the ability to work with multiple developers in parallel on a single application. Like us, you’ve likely dealt with painful merge conflicts in the past when committing your work to a version control system. A well-designed, loosely coupled system will, among other things, reduce the amount of merge conflicts that you’ll have. When more developers start working on Mary’s application, it’ll become harder and harder to work effectively without stepping on each other’s toes.
• 可测试性 — 我们已经确定换出数据访问层目前是不可能的。然而，在没有数据库的情况下测试代码是进行单元测试的先决条件。但即使进行了集成测试，Mary 也可能需要更换部分代码，而当前的设计让这很难做到。因此，Mary 的应用程序是不可测试的。
• Testability — We already established that swapping out the data access layer is currently impossible. Testing code without a database, however, is a prerequisite for doing unit testing. But even with integration testing, Mary will likely need some parts of the code to be swapped out, and the current design makes this hard. Mary’s application is, therefore, not Testable.

此时，您可能会问自己所需的依赖图应该是什么样子。对于最高程度的重用，最低数量的依赖是可取的。另一方面，如果根本没有依赖关系，应用程序将变得毫无用处。

At this point, you may ask yourself what the desired dependency graph should look like. For the highest degree of reuse, the lowest amount of dependencies is desirable. On the other hand, the application would become rather useless if there were no dependencies at all.

您需要哪些依赖项以及它们应指向的方向取决于需求。但是因为我们已经确定我们无意用完全不同的实现替换域层，所以可以安全地假设其他层可以安全地依赖它。图 2.10对您将在下一章中编写的松耦合应用程序进行了大剧透，但它确实显示了所需的依赖关系图。

Which dependencies you need and in what direction they should point depends on the requirements. But because we’ve already established that we have no intention of replacing the domain layer with a completely different implementation, it’s safe to assume that other layers can safely depend on it. Figure 2.10 contains a big spoiler for the loosely coupled application you’ll write in the next chapter, but it does show the desired dependency graph.

该图显示了我们如何反转域和数据访问层之间的依赖关系。我们将在下一章中详细介绍如何执行此操作。

The figure shows how we inverted the dependency between the domain and data access layers. We’ll go into more detail on how to do this in the next chapter.

2.3.3 杂项其他问题

2.3.3 Miscellaneous other issues

我们想指出一些应该解决的 Mary 代码的其他问题。

We’d like to point out a few other issues with Mary’s code that ought to be addressed.

• 大多数领域模型似乎是在数据访问层中实现的. Product领域层引用数据访问层是一个技术问题，而数据访问层将类定义为类是一个概念问题. 公共Product类属于领域模型。
• Most of the domain model seems to be implemented in the data access layer. Whereas it’s a technical problem that the domain layer references the data access layer, it’s a conceptual problem that the data access layer defines such a class as the Product class. A public Product class belongs in the domain model.
• 根据 Jens 的建议，Mary 决定在 UI 中实施确定用户是否为首选客户的代码。但是如何将客户识别为首选客户是一个业务逻辑，因此应该在领域模型中实现。Jens 关于关注点分离的论点和单一职责原则不是将代码放在错误位置的借口。在单个库中遵循单一职责原则是完全可能的——这是预期的方法。
• On Jens’ advice, Mary decided to implement in the UI the code that determines whether a user is a preferred customer. But how a customer is identified as a preferred customer is a piece of business logic, so it should be implemented in the domain model. Jens’ argument about Separation of Concerns and the Single Responsibility Principle is no excuse for putting code in the wrong place. Following the Single Responsibility Principle within a single library is entirely possible — that’s the expected approach.
• Mary 从CommerceContext类中的配置文件加载连接字符串（如清单 2.2所示）。从其消费者的角度来看，完全隐藏了对该配置值的依赖。正如我们在讨论清单 2.2时提到的，这种隐含包含一个陷阱。

  虽然配置已编译应用程序的能力很重要，但只有完成的应用程序才应该依赖配置文件。对于可重用的库来说，调用者可以强制配置它更加灵活，而不是自己读取配置文件。最后，最终调用者是应用程序的入口点。那时，所有相关的配置数据都可以在启动时直接从配置文件中读取，并根据需要提供给底层库。我们希望CommerceContext需要明确的配置。

• Mary loaded the connection string from the configuration file from within theCommerceContextclass (shown in listing 2.2). From the perspective of its consumers, the dependency on this configuration value is completely hidden. As we alluded to when discussing listing 2.2, this implicitness contains a trap.

  Although the ability to configure a compiled application is important, only the finished application should rely on configuration files. It’s more flexible for reusable libraries to be imperatively configurable by their callers, instead of reading configuration files themselves. In the end, the ultimate caller is the application’s entry point. At that point, all relevant configuration data can be read from a configuration file directly at startup and fed to the underlying libraries as needed. We want the configuration that CommerceContext requires to be explicit.

• 视图（如清单 2.5所示）似乎包含太多功能。它执行强制转换和特定的字符串格式化。此类功能应移至基础模型。
• The view (as shown in listing 2.5) seems to contain too much functionality. It performs casts and specific string formatting. Such functionality should be moved to the underlying model.

2.4 结论

2.4 Conclusion

编写紧密耦合的代码非常容易。即使当 Mary 明确打算编写一个三层应用程序时，它也变成了一个大体上单一的意大利面条代码。⁵   （当我们谈论分层时，我们称之为烤宽面条。）

It’s surprisingly easy to write tightly coupled code. Even when Mary set out with the express intent of writing a three-layer application, it turned into a largely monolithic piece of Spaghetti Code.⁵  (When we’re talking about layering, we call this Lasagna.)

编写紧密耦合的代码如此容易的众多原因之一是语言特性和我们的工具已经把我们拉向了那个方向。如果你需要一个对象的新实例，你可以使用new关键字。如果您没有对所需程序集的引用，Visual Studio 可以轻松添加。但是每次你使用new关键字，你引入了一个紧耦合。正如第 1 章所讨论的，并不是所有的紧耦合都是不好的，但是你应该努力防止与易变依赖的紧耦合.

One of the many reasons that it’s so easy to write tightly coupled code is that both the language features and our tools already pull us in that direction. If you need a new instance of an object, you can use the new keyword. If you don’t have a reference to the required assembly, Visual Studio makes it easy to add. But every time you use the new keyword, you introduce a tight coupling. As discussed in chapter 1, not all tight coupling is bad, but you should strive to prevent tight coupling to Volatile Dependencies.

到现在为止，您应该开始理解是什么使紧密耦合的代码如此成问题，但我们还没有向您展示如何解决这些问题。在下一章中，我们将向您展示一种更具组合性的方法来构建具有与 Mary 构建的相同功能的应用程序。我们还将同时解决第 2.3.3 节中讨论的那些其他问题。

By now you should begin to understand what it is that makes tightly coupled code so problematic, but we’ve yet to show you how to fix these problems. In the next chapter, we’ll show you a more composable way of building an application with the same features as the one Mary built. We’ll also address those other issues discussed in section 2.3.3 at the same time.

概括

Summary

• 复杂的软件必须解决许多不同的问题，例如安全性、诊断、操作、性能和可扩展性。
• Complex software must address lots of different concerns, such as security, diagnostics, operations, performance, and extensibility.
• 松散耦合鼓励您孤立地解决所有应用程序问题，但最终您仍必须组合这组复杂的问题。
• Loose coupling encourages you to address all application concerns in isolation, but ultimately you must still compose this complex set of concerns.
• 创建紧密耦合的代码很容易。虽然并非所有的紧耦合都是不好的，但与易失性依赖关系的紧耦合是而且应该避免的。
• It’s easy to create tightly coupled code. Although not all tight coupling is bad, tight coupling to Volatile Dependencies is and should be avoided.
• 在 Mary 的应用程序中，由于领域层依赖于数据访问层，因此无法用不同的数据访问层替换数据访问层。她的应用程序中的紧耦合导致 Mary 失去了松耦合提供的好处：后期绑定、可扩展性、可维护性、可测试性和并行开发。
• In Mary’s application, because the domain layer depended on the data access layer, there was no way to replace the data access layer with a different one. The tight coupling in her application caused Mary to lose the benefits that loose coupling provides: late binding, extensibility, maintainability, Testability, and parallel development.
• 只有完成的应用程序才应该依赖配置文件。应用程序的其他部分不应该从配置文件请求值，而应该由它们的调用者配置。
• Only the finished application should rely on configuration files. Other parts of the application shouldn’t request values from a configuration file, but should instead be configurable by their callers.
• 单一职责原则指出每个类应该只有一个改变的理由。
• The Single Responsibility Principle states that each class should only have one reason to change.
• 单一职责原则可以从内聚的角度来看。内聚被定义为类或模块的元素的功能相关性。相关性越低，凝聚力越低；凝聚力越低，类违反单一职责原则的可能性就越大。
• The Single Responsibility Principle can be viewed from the perspective of cohesion. Cohesion is defined as the functional relatedness of the elements of a class or module. The lower the amount of relatedness, the lower the cohesion; and the lower the cohesion, the greater the chance a class violates the Single Responsibility Principle.

在这一章当中

In this chapter

• 重新设计 Mary 的电子商务应用程序使其松散耦合
• Redesigning Mary’s e-commerce application to become loosely coupled
• 分析松散耦合的应用程序
• Analyzing that loosely coupled application
• 评估松散耦合的应用程序
• Evaluating that loosely coupled application

在烤牛排时，一个重要的做法是让肉在切成薄片之前静置。休息时，果汁会重新分配，结果会变得更加多汁。另一方面，如果你切得太早，所有的汁液都会用完，你的肉会变得更干，更不好吃。让这种情况发生将是一种可怕的耻辱，因为您想为您的客人提供您可以提供的最佳品尝体验。尽管了解任何职业的最佳实践都很重要，但了解不良实践并理解为什么这些实践会导致不尽如人意的结果也同样重要。

When it comes to grilling steak, an important practice is to let the meat rest before you cut it into slices. When resting, the juices redistribute, and the results get juicier. If, on the other hand, you cut it too soon, all the juice runs out, and your meat gets drier and less tasty. It’d be a terrible shame to let this happen, because you’d like to give your guests the best tasting experience you can deliver. Although it’s important to know the best practices for any profession, it’s just as important to know the bad practices and to understand why those lead to unsatisfactory results.

了解好的和坏的做法之间的区别对于学习来说是必不可少的。这就是为什么上一章完全致力于紧耦合代码的示例和分析：分析为您提供了原因。

Knowing the difference between good and bad practices is essential to learning. This is why the previous chapter was completely devoted to an example and analysis of tightly coupled code: the analysis provided you with the why.

总而言之，松散耦合提供了许多好处——后期绑定、可扩展性、可维护性、可测试性和并行开发。使用紧密耦合，您将失去这些好处。虽然并非所有的紧耦合都是不可取的，但你应努力避免与Volatile Dependencies的紧耦合。此外，您可以使用依赖注入 (DI) 来解决在分析过程中发现的问题。因为 DI 与 Mary 创建她的应用程序的方式截然不同，所以我们不打算修改她现有的代码。相反，我们将从头开始重新创建它。

To summarize, loose coupling provides a number of benefits — late binding, extensibility, maintainability, Testability, and parallel development. With tight coupling, you lose those benefits. Although not all tight coupling is undesirable, you should strive to avoid tight coupling to Volatile Dependencies. Moreover, you can use Dependency Injection (DI) to solve the issues that were discovered during that analysis. Because DI is a radical departure from the way Mary created her application, we’re not going to modify her existing code. Rather, we’re going to re-create it from scratch.

让我们首先简要回顾一下 Mary 的申请。我们还将讨论我们将如何处理重写以及完成后所需的结果。

Let’s start with a short recap of Mary’s application. We’ll also discuss how we’ll approach the rewrite and what the desired result will look like when we’ve finished.

3.1 重建电子商务应用

3.1 Rebuilding the e-commerce application

第2章分析Mary的应用，得出Volatile Dependencies在不同层之间紧密耦合。正如图 3.1中 Mary 的应用程序的依赖关系图所示，领域层和 UI 层都依赖于数据访问层。

The analysis of Mary’s application in chapter 2 concluded that Volatile Dependencies were tightly coupled across the different layers. As the dependency graph of Mary’s application in figure 3.1 shows, both the domain layer and the UI layer depend on the data access layer.

本章的目标是反转领域层和数据访问层之间的依赖关系。这意味着不是域层依赖于数据访问层，数据访问层将依赖领域层，如图3.2所示。

What we’ll aim to achieve in this chapter is to invert the dependency between the domain layer and the data access layer. This means that instead of the domain layer depending on the data access layer, the data access layer will depend on the domain layer, as shown in figure 3.2.

通过创建此反转，我们允许替换数据访问层，而不必完全重写应用程序。（这与 Mary 开发她的应用程序的方式截然不同。）我们还将在此过程中应用几种模式。然后我们将应用构造函数注入，我们在第 1 章讨论过。最后，我们还将使用方法注入和Composition Root，我们将在进行时进行讨论。

By creating this inversion, we allow the data access layer to be replaced without having to completely rewrite the application. (This is a radical departure from the way Mary developed her application.) We’ll also apply several patterns along the way. Then we’ll apply Constructor Injection, which we discussed in chapter 1. And finally, we’ll also use Method Injection and Composition Root, which we’ll discuss as we go.

当我们专注于分离应用程序关注点时，这种方法将导致更多的类。Mary 定义了四个类，我们将定义九个类和三个接口。图 3.3更深入地研究了应用程序，并显示了我们将在本章中创建的类和接口。

This approach will lead to quite a few more classes as we focus on separating the application concerns. Where Mary defined four classes, we’ll define nine classes and three interfaces. Figure 3.3 drills a little deeper into the application and shows the classes and interfaces we’ll create throughout this chapter.

图 3.4显示了应用程序中的主要类将如何交互。在本章的最后，我们将再次看一下该图的更详细的版本。

Figure 3.4 shows how the main classes in the application will interact. At the end of this chapter, we’ll take a look at a slightly more detailed version of this diagram again.

当我们编写软件时，我们更喜欢从最重要的地方开始——利益相关者最能看到的部分。在 Mary 的电子商务应用程序中，这通常是 UI。从那里开始，我们开始工作，添加更多功能，直到完成一个功能；然后我们继续下一个。这种由外而内的技术帮助我们专注于所请求的功能，而不会过度设计解决方案。

When we write software, we prefer to start in the most significant place — the part that has most visibility to our stakeholders. As in Mary’s e-commerce application, this is often the UI. From there, we work our way in, adding more functionality until one feature is done; then we move on to the next. This outside-in technique helps us to focus on the requested functionality without overengineering the solution.

在第 2 章中，玛丽使用了相反的方法。她从数据访问层开始，从内到外工作. 如果我们说由内而外的工作是糟糕的，这对我们来说有点苛刻，但正如您稍后将看到的那样，由外而内的方法可以让您更快地反馈您正在构建的内容。因此，我们将以相反的顺序构建应用程序，从 UI 层开始，继续构建域层，最后构建数据访问层。

In chapter 2, Mary used the opposite approach. She started with the data access layer and worked her way out, working inside-out. It would be harsh for us to say that working inside-out is bad, but as you’ll see later, the outside-in approach gives you quicker feedback on what you’re building. We’ll therefore build the application in the opposite order, starting with the UI layer, continuing with the domain layer, and then building the data access layer last.

因为我们实践测试驱动开发（测试驱动开发)，一旦我们的由外向内方法提示我们创建一个新类，我们就开始编写单元测试。尽管我们编写了单元测试来创建这个示例，但 TDD 并不是实现和使用 DI 所必需的，因此我们不会在本书中展示这些测试。如果您有兴趣，本书附带的源代码包括测试。让我们直接进入我们的项目并从 UI 开始。

Because we practice Test-Driven Development (TDD), we start by writing unit tests as soon as our outside-in approach prompts us to create a new class. Although we wrote unit tests to create this example, TDD isn’t required to implement and use DI, so we’re not going to show these tests in the book. If you’re interested, the source code that accompanies this book includes the tests. Let’s dive right into our project and begin with the UI.

3.1.1 构建更易于维护的 UI

3.1.1 Building a more maintainable UI

Mary 对特色产品列表的规范是编写一个应用程序，从数据库中提取这些项目并将它们显示在列表中（再次显示在图 3.5中）。因为我们知道项目利益相关者主要对视觉结果感兴趣，所以 UI 似乎是一个很好的起点。

Mary’s specification for the list of featured products was to write an application that extracts those items from the database and displays them in a list (shown again in figure 3.5). Because we know that the project stakeholders will mainly be interested in the visual result, the UI seems like a good place to start.

打开 Visual Studio 后要做的第一件事是向解决方案中添加一个新的 ASP.NET Core MVC 应用程序。因为特色产品列表需要放在首页，所以您首先要修改 Index.cshtml 文件以包含以下清单中显示的标记。^2个 

The first thing you do after opening Visual Studio is add a new ASP.NET Core MVC application to the solution. Because the list of featured products needs to go on the front page, you start by modifying the Index.cshtml file to include the markup shown in the following listing.² 

清单 3.1 Index.cshtml 视图标记

Listing 3.1 Index.cshtml view markup

@model FeaturedProductsViewModel

<h2>Featured Products</h2>
<div>
    @foreach (ProductViewModel product in this.Model.Products)
    {
        <div>@product.SummaryText</div>
    }
</div>

请注意与 Mary 的原始标记相比，清单 3.1更加清晰。

Notice how much cleaner listing 3.1 is compared to Mary’s original markup.

清单 3.2 MaryIndex在第 2 章中的原始视图标记

Listing 3.2 Mary’s original Index view markup from chapter 2

<h2>Featured Products</h2>
<div>
@{
    var products = (IEnumerable<Product>)this.ViewData["Products"];

    foreach (Product product in products)
    {
        <div>@product.Name (@product.UnitPrice.ToString("C"))</div>
    }
}
</div>

第一个改进是在迭代成为可能之前，您不再将字典项转换为产品序列。您可以使用 MVC 的特殊@model指令轻松完成此操作. 这意味着该Model物业页面的FeaturedProductsViewModel类型. 使用该@model指令，MVC 将确保将从控制器返回的值强制转换为该FeaturedProductsViewModel类型。SummaryText其次，直接从属性中拉取整个产品显示字符串的ProductViewModel。

The first improvement is that you no longer cast a dictionary item to a sequence of products before iteration is possible. You accomplished this easily by using MVC’s special @model directive. This means that the Model property of the page is of the FeaturedProductsViewModel type. Using the @model directive, MVC will ensure that the value returned from the controller will be cast to the FeaturedProductsViewModel type. Secondly, the entire product display string is pulled directly from the SummaryText property of ProductViewModel.

这两项改进都与封装视图行为的视图特定模型的引入有关。这些模型是普通的旧 CLR 对象(POCO). ³  以下列表提供了它们结构的概要。

Both improvements are related to the introduction of view-specific models that encapsulate the behavior of the view. These models are Plain Old CLR Objects (POCO).³  The following listing provides an outline of their structure.

清单 3.3 和类FeaturedProductsViewModelProductViewModel

Listing 3.3 FeaturedProductsViewModel and ProductViewModel classes

public class FeaturedProductsViewModel
{
    public FeaturedProductsViewModel(
        IEnumerable<ProductViewModel> products)
    {
        this.Products = products;
    }

    public IEnumerable<ProductViewModel> Products    ①  
        { get; }
}

public class ProductViewModel
{
    private static CultureInfo PriceCulture = new CultureInfo("en-US");

    public ProductViewModel(string name, decimal unitPrice)
    {
        this.SummaryText = string.Format(PriceCulture,
            "{0} ({1:C})", name, unitPrice);
    }

    public string SummaryText { get; }    ②  
}

视图模型的使用简化了视图，这很好，因为视图更难测试。它还使 UI 设计人员更容易处理应用程序。

The use of view models simplifies the view, which is good because views are harder to test. It also makes it easier for a UI designer to work on the application.

HomeController必须返回一个带有 的实例的视图，清单 3.1FeaturedProductsViewModel中的代码才能工作。作为第一步，这可以在内部像这样实现：HomeController

HomeController must return a view with an instance of FeaturedProductsViewModel for the code in listing 3.1 to work. As a first step, this can be implemented inside HomeController like this:

public ViewResult Index()
{
    var vm = new FeaturedProductsViewModel(new[]    ①  
    {    ①  
        new ProductViewModel("Chocolate", 34.95m),    ①  
        new ProductViewModel("Asparagus", 39.80m)    ①  
    });    ①  

    return this.View(vm);    ②  
}

我们在方法中硬编码了打折产品列表Index。这不是期望的最终结果，但它使 Web 应用程序能够无错误地执行，并允许我们向利益相关者展示一个不完整但正在运行的应用程序示例（存根），供他们评论。

We hard-coded the list of discounted products inside the Index method. This isn’t the desired end result, but it enables the web application to execute without error and allows us to show the stakeholders an incomplete, but running example of the application (a stub) for them to comment on.

在这个阶段，只实现了 UI 层的存根；域层和数据访问层的完整实现仍然存在。从 UI 开始的一个优势是我们已经拥有可以运行和测试的软件。将此与玛丽在可比阶段的进步进行对比。直到很晚的时候，Mary 才到达可以运行该应用程序的地步。图 3.6显示了存根的 Web 应用程序。

At this stage, only a stub of the UI layer has been implemented; a full implementation of the domain layer and data access layer still remains. One advantage of starting with the UI is that we already have software we can run and test. Contrast this with Mary’s progress at a comparable stage. Only at a much later stage does Mary arrive at a point where she can run the application. Figure 3.6 shows the stubbed web application.

为了HomeController履行其义务并做任何感兴趣的事情，它从领域层请求特色产品列表。这些产品需要应用折扣。在第 2 章中，Mary 在她的ProductService课程中包含了这个逻辑，我们也将这样做。

For our HomeController to fulfill its obligations, and to do anything of interest, it requests a list of featured products from the domain layer. These products need to have discounts applied. In chapter 2, Mary wrapped this logic in her ProductService class, and we’ll do that too.

on的Index方法HomeController应该使用ProductService实例来检索特色产品列表，将它们转换为ProductViewModel实例，然后将它们添加到FeaturedProductsViewModel. HomeController然而，从 的角度来看，它ProductService是一个Volatile Dependency ，因为它是一个尚不存在且仍在开发中的 Dependency。如果我们以后要HomeController隔离测试，ProductService并行开发，或者替换或者拦截它，就需要引入一个Seam。

The Index method on HomeController should use the ProductService instance to retrieve the list of featured products, convert those to ProductViewModel instances, and then add those to FeaturedProductsViewModel. From the perspective of HomeController, however, ProductService is a Volatile Dependency because it’s a Dependency that doesn’t yet exist and is still in development. If we want to test HomeController in isolation, develop ProductService in parallel, or replace or Intercept it in the future, we need to introduce a Seam.

回想一下对 Mary 的实现的分析，依赖于易失性依赖是一个大罪。一旦这样做，您就会与刚刚使用的类型紧密耦合。为了避免这种紧密耦合，我们将引入一个接口并使用一种称为构造函数注入的技术；实例是如何创建的，由谁创建的，与HomeController.

Recall from the analysis of Mary’s implementation that depending on Volatile Dependencies is a cardinal sin. As soon as you do that, you’re tightly coupled with the type just used. To avoid this tight coupling, we’ll introduce an interface and use a technique called Constructor Injection; how the instance is created, and by whom, is of no concern to HomeController.

清单 3.4 HomeController类

Listing 3.4 HomeController class

public class HomeController : Controller
{
    private readonly IProductService productService;

    public HomeController(
        IProductService productService)    ①  
    {
        if (productService == null)    ②  
            throw new ArgumentNullException(
                "productService");

        this.productService = productService;    ③  
    }

    public ViewResult Index()
    {
        IEnumerable<DiscountedProduct> products =
            this.productService.GetFeaturedProducts();    ④  

        var vm = new FeaturedProductsViewModel(    ⑤  
            from product in products
            select new ProductViewModel(product));    ⑥  

        return this.View(vm);
    }
}

正如我们在第 1 章中所述，构造函数注入是通过将所需依赖项指定为类构造函数的参数来静态定义所需依赖项列表的行为。这正是HomeController所做的。在其公共构造函数中，它定义了正确运行所需的依赖项。

As we stated in chapter 1, Constructor Injection is the act of statically defining the list of required Dependencies by specifying them as parameters to the class’s constructor. This is exactly what HomeController does. In its public constructor, it defines what Dependencies it requires for it to function correctly.

第一次听说构造函数注入，我们很难理解真正的好处。它不会将控制依赖关系的负担推给其他一些类吗？是的，确实如此——这就是重点。在n层应用程序中，您可以将该负担一直推到应用程序的顶部，进入组合根。

The first time we heard about Constructor Injection, we had a hard time understanding the real benefit. Doesn’t it push the burden of controlling the Dependency onto some other class? Yes, it does — and that’s the whole point. In an n-layer application, you can push that burden all the way to the top of the application into a Composition Root.

因为我们添加了一个带有参数的构造函数，所以如果没有DependencyHomeController就不可能创建一个，这正是我们这样做的原因。但这确实意味着应用程序的主屏幕已损坏，因为 MVC 不知道我们必须如何创建 — 除非您以其他方式指示 MVC。HomeControllerHomeController

Because we added a constructor with an argument to HomeController, it’ll be impossible to create a HomeController without that Dependency, and that’s exactly why we did that. But that does mean that the application’s home screen is broken, because MVC has no idea how our HomeController must be created — unless you instruct MVC otherwise.

事实上，创建HomeController不是 UI 层的关注点；这是Composition Root的责任。⁵  至此，我们认为UI层已经完成，后面我们会回过头来创建HomeController。图 3.7显示了实现图 3.2中设想的体系结构的当前状态。

In fact, the creation of HomeController isn’t a concern of the UI layer; it’s the responsibility of the Composition Root.⁵  Because of this, we consider the UI layer completed, and we’ll come back to the creation of HomeController later on. Figure 3.7 shows the current state of implementing the architecture envisioned in figure 3.2.

这将我们带到重新创建电子商务应用程序的下一阶段，即领域模型。

This leads us to the next stage in the re-creation of our e-commerce application, the domain model.

3.1.2 构建独立领域模型

3.1.2 Building an independent domain model

域模型是我们添加到解决方案中的普通 C# 库。该库将包含 POCO 和接口。POCO 将对域建模，而接口提供抽象，将作为我们进入域模型的主要外部入口点。他们将提供契约，域模型通过契约与即将到来的数据访问层进行交互。

The domain model is a plain, vanilla C# library that we add to the solution. This library will contain POCOs and interfaces. The POCOs will model the domain while the interfaces provide Abstractions that will serve as our main external entry points into the domain model. They’ll provide the contract through which the domain model interacts with the forthcoming data access layer.

上HomeController一节中交付的还没有编译，因为我们还没有定义IProductService 抽象。在本节中，我们将向电子商务应用程序添加一个新的域层项目，并从 MVC 项目中引用域层项目，就像 Mary 所做的那样。结果没问题，但我们会推迟到 3.2 节再进行依赖图分析，以便我们可以为您提供全貌。以下清单显示了IProductService 抽象。

The HomeController delivered in the previous section doesn’t compile yet because we haven’t defined the IProductService Abstraction. In this section, we’ll add a new domain layer project to the e-commerce application and a reference to the domain layer project from the MVC project, like Mary did. That will turn out OK, but we’ll postpone doing a dependency graph analysis until section 3.2 so that we can provide you with the full picture. The following listing shows the IProductService Abstraction.

清单 3.5 IProductService界面

Listing 3.5 IProductService interface

public interface IProductService
{
    IEnumerable<DiscountedProduct> GetFeaturedProducts();
}

IProductService代表我们当前领域层的核心，因为它连接了 UI 层和数据访问层。它是将我们的初始应用程序绑定在一起的粘合剂。

IProductService represents the heart of our current domain layer in that it bridges the UI layer with the data access layer. It’s the glue that binds our initial application together.

IProductService 抽象的唯一成员是GetFeaturedProducts方法. DiscountedProduct它返回实例的集合。每个DiscountedProduct包含一个Name和一个UnitPrice。这是一个简单的 POCO 类，如下一个清单所示，这个定义足以让我们编译我们的 Visual Studio 解决方案。

The sole member of the IProductService Abstraction is the GetFeaturedProducts method. It returns a collection of DiscountedProduct instances. Each DiscountedProduct contains a Name and a UnitPrice. It’s a simple POCO class, as can be seen in the next listing, and this definition gives us enough to compile our Visual Studio solution.

清单 3.6 DiscountedProduct POCO 类

Listing 3.6 DiscountedProduct POCO class

public class DiscountedProduct
{
    public DiscountedProduct(string name, decimal unitPrice)
    {
        if (name == null) throw new ArgumentNullException("name");

        this.Name = name;
        this.UnitPrice = unitPrice;
    }

    public string Name { get; }
    public decimal UnitPrice { get; }
}

针对接口而非具体类编程的原则是 DI 的基石。正是这一原则让您可以用一个具体实现替换另一个。在继续之前，我们应该花点时间了解一下接口在本次讨论中的作用。

The principle of programming to interfaces instead of concrete classes is a cornerstone of DI. It’s this principle that lets you replace one concrete implementation with another. Before continuing, we should take a quick moment to recognize the role of interfaces in this discussion.

接下来我们将编写我们的ProductService实现。此类的GetFeaturedProducts方法ProductService应使用IProductRepository实例来检索特色产品列表、应用任何折扣并返回DiscountedProduct实例列表。

Next we’ll write our ProductService implementation. The GetFeaturedProducts method of this ProductService class should use an IProductRepository instance to retrieve the list of featured products, apply any discounts, and return a list of DiscountedProduct instances.

存储库模式提供了对数据访问的通用抽象，因此我们将IProductRepository在域模型库中定义一个抽象。^6个 

A common abstraction over data access is provided by the Repository pattern, so we’ll define an IProductRepository abstraction in the domain model library.⁶ 

清单 3.7 IProductRepository

Listing 3.7 IProductRepository

public interface IProductRepository
{
    IEnumerable<Product> GetFeaturedProducts();
}

IProductRepository是数据访问层的接口，从持久性存储返回“原始”实体。相比之下，IProductService应用业务逻辑，例如本例中的折扣，并将实体转换为范围更窄的对象。一个成熟的存储库将有更多的方法来查找和修改产品，但是，遵循由外而内的原则，我们只定义手头任务所需的类和成员。向代码添加功能比删除任何东西都容易。

IProductRepository is the interface to the data access layer, returning “raw” Entities from the persistence store. By contrast, IProductService applies business logic, such as the discount in this case, and converts the Entities to a narrower-focused object. A full-blown Repository would have more methods to find and modify products, but, following the outside-in principle, we only define the classes and members needed for the task at hand. It’s easier to add functionality to code than it is to remove anything.

因为我们的目标是反转领域层和数据访问层之间的依赖关系，IProductRepository所以定义在领域层。在下一节中，我们将创建一个实现作为数据访问层的一部分。这允许我们的依赖指向域层。IProductRepository

Because our goal is to invert the dependency between the domain layer and the data access layer, IProductRepository is defined in the domain layer. In the next section, we’ll create an implementation of IProductRepository as part of the data access layer. This allows our dependency to point at the domain layer.

Product班级_也是用最少的成员实现的，如以下清单所示。

The Product class is also implemented with the bare minimum of members, as shown in the following listing.

清单 3.8 Product实体

Listing 3.8 ProductEntity

public class Product
{
    public string Name { get; set; }    ①  
    public decimal UnitPrice { get; set; }    ①  
    public bool IsFeatured { get; set; }    ①  

    public DiscountedProduct ApplyDiscountFor(
        IUserContext user)    ②  
    {
        bool preferred =    ③  
            user.IsInRole(Role.PreferredCustomer);    ③  
    ③  
        decimal discount = preferred ? .95m : 1.00m;    ③  
    ③  
        return new DiscountedProduct(    ③  
            name: this.Name,    ③  
            unitPrice: this.UnitPrice * discount);    ③  
    }
}

图 3.8说明了ProductService及其Dependencies之间的关系。

Figure 3.8 illustrates the relationship between ProductService and its Dependencies.

GetFeaturedProducts方法_类的ProductService应该使用一个IProductRepository实例来检索特色产品列表，应用任何折扣，并返回一个DiscountedProduct实例列表。ProductService班级_对应于 Mary 的同名类，但现在是纯域模型类，因为它没有对数据访问层的硬编码引用。对于我们的HomeController，我们将再次使用构造函数注入放弃对其易失性依赖项的控制，如下所示。

The GetFeaturedProducts method of the ProductService class should use an IProductRepository instance to retrieve the list of featured products, apply any discounts, and return a list of DiscountedProduct instances. The ProductService class corresponds to Mary’s class of the same name, but is now a pure domain model class because it doesn’t have a hard-coded reference to the data access layer. As with our HomeController, we’re again going to relinquish control of its Volatile Dependencies using Constructor Injection, as shown next.

ProductService带有构造函数注入的清单 3.9

Listing 3.9 ProductService with Constructor Injection

public class ProductService : IProductService
{
    private readonly IProductRepository repository;
    private readonly IUserContext userContext;

    public ProductService(
        IProductRepository repository,    ①  
        IUserContext userContext)    ①  
    {
        if (repository == null)
            throw new ArgumentNullException("repository");
        if (userContext == null)
            throw new ArgumentNullException("userContext");

        this.repository = repository;
        this.userContext = userContext;
    }

    public IEnumerable<DiscountedProduct> GetFeaturedProducts()
    {
        return
            from product in this.repository    ②  
                .GetFeaturedProducts()    ②  
            select product    ②  
                .ApplyDiscountFor(this.userContext);    ③  
    }
}

除了IProductRepository，ProductService构造函数还需要一个实例IUserContext：

Besides an IProductRepository, the ProductService constructor requires an instance of IUserContext:

public interface IUserContext
{
    bool IsInRole(Role role);
}

public enum Role { PreferredCustomer }

这是与 Mary 的实现的另一个不同之处，后者仅将布尔值作为GetFeaturedProducts方法的参数，指示用户是否是首选客户。因为决定用户是否是首选客户是域层的一部分，所以将其显式建模为Dependency更为正确。除此之外，有关代表其运行请求的用户的信息是上下文相关的。我们不希望每个控制器都负责收集这些信息。这将是重复的并且容易出错，并且可能导致意外的安全漏洞。

This is another departure from Mary’s implementation, which only took a boolean value as argument to the GetFeaturedProducts method, indicating whether the user is a preferred customer. Because deciding whether a user is a preferred customer is a piece of the domain layer, it’s more correct to explicitly model this as a Dependency. Besides that, information about the user on whose behalf the request is running is contextual. We don’t want every controller to be responsible for gathering this information. That would be repetitive and error prone, and might lead to accidental security bugs.

我们不是让 UI 层向领域层提供此信息，而是让此信息的检索成为ProductService. 该IUserContext接口允许ProductService检索有关当前用户的信息，而无需HomeController提供此信息。HomeController不需要知道哪些角色被授权获得折扣价，也不容易无意中通过传递而不是HomeController启用折扣。这降低了 UI 层的整体复杂性。truefalse

Instead of letting the UI layer provide this information to the domain layer, we allow the retrieval of this information to become an implementation detail of ProductService. The IUserContext interface allows ProductService to retrieve information about the current user without HomeController needing to provide this. HomeController doesn’t need to know which role(s) are authorized for a discount price, nor is it easy for HomeController to inadvertently enable the discount by passing, for example, true instead of false. This reduces the overall complexity of the UI layer.

虽然 .NET 基类库（BCL）包括一个IPrincipal接口，它代表了对应用程序用户进行建模的标准方法，该接口本质上是通用的，并不是为我们的应用程序的特殊需求量身定制的。相反，我们让应用程序定义抽象。

Although the .NET Base Class Library (BCL) includes an IPrincipal interface, which represents a standard way of modeling application users, that interface is generic in nature and isn’t tailored for our application’s special needs. Instead, we let the application define the Abstraction.

该ProductService.GetFeaturedProducts方法将IUserContext 依赖项传递给该Product.ApplyDiscountFor方法。这种技术被称为方法注入。方法注入在短命的情况下特别有用像Entities这样的对象（例如我们的例子中的Product Entity）需要Dependencies。尽管细节有所不同，但主要技术保持不变。我们将在第 4 章更详细地讨论这种模式。在这个阶段，应用程序根本不起作用。那是因为仍然存在三个问题：

The ProductService.GetFeaturedProducts method passes the IUserContext Dependency on to the Product.ApplyDiscountFor method. This technique is known as Method Injection. Method Injection is particularly useful in cases where short-lived objects like Entities (such as the Product Entity, in our case) need Dependencies. Although the details vary, the main technique remains the same. We’ll discuss this pattern in more detail in chapter 4. At this stage, the application doesn’t work at all. That’s because three problems remain:

• 没有具体的实现IProductRepository。这很容易解决。在下一节中，我们将实现一个从数据库中读取特色产品的实体。SqlProductRepository
• There’s no concrete implementation of IProductRepository. This is easily solved. In the next section, we’ll implement a concrete SqlProductRepository that reads the featured products from the database.
• 没有具体的实现IUserContext。我们也将在下一节中对此进行介绍。
• There’s no concrete implementation ofIUserContext. We’ll take a look at this in the next section too.
• MVC 框架不知道要使用哪种具体类型。IProductService这是因为我们在 的构造函数中引入了一个类型的抽象参数HomeController。这个问题可以通过多种方式解决，但我们更喜欢开发一个自定义的Microsoft.AspNetCore.Mvc.Controllers.IControllerActivator. 这是如何完成的超出了本章的范围，但这是我们将在第 7 章中讨论的主题。只要说这个自定义工厂将创建一个具体的实例ProductService并将其提供给 的构造函数就足够了HomeController。
• The MVC framework doesn’t know which concrete type to use. This is because we introduced an abstract parameter of type IProductService to the constructor of HomeController. This issue can be solved in various ways, but our preference is to develop a custom Microsoft.AspNetCore.Mvc.Controllers.IControllerActivator. How this is done is outside the scope of this chapter, but it’s a subject that we’ll discuss in chapter 7. Suffice it to say that this custom factory will create an instance of the concrete ProductService and supply it to the constructor of HomeController.

在域层中，我们仅使用域层中定义的类型和.NET BCL 的稳定依赖项。领域层的概念被实现为 POCO。在此阶段，只表示一个概念，即Product. 领域层必须能够与外界（如数据库）进行通信。这种需求被建模为抽象（例如存储库），我们必须在领域层变得有用之前用具体的实现替换它。图 3.9显示了实现图 3.2中设想的体系结构的当前状态。

In the domain layer, we work only with types defined within the domain layer and Stable Dependencies of the .NET BCL. The concepts of the domain layer are implemented as POCOs. At this stage, there’s only a single concept represented, namely, a Product. The domain layer must be able to communicate with the outside world (such as databases). This need is modeled as Abstractions (such as Repositories) that we must replace with concrete implementations before the domain layer becomes useful. Figure 3.9 shows the current state of implementing the architecture envisioned in figure 3.2.

我们成功地编译了我们的领域模型。这意味着我们创建了一个独立于数据访问层的域模型，我们仍然需要创建它。但在我们开始之前，有几点我们想更详细地解释一下。

We succeeded in making our domain model compile. This means that we created a domain model that’s independent of the data access layer, which we still need to create. But before we get to that, there are a few points we’d like to explain in more detail.

依赖倒置原则

Dependency Inversion Principle

我们试图用 DI 完成的大部分工作都与依赖倒置原则有关。⁸  该原则指出，我们应用程序中的高层模块不应依赖于低层模块；相反，两个级别的模块都应该依赖于Abstractions。

Much of what we’re trying to accomplish with DI is related to the Dependency Inversion Principle.⁸  This principle states that higher-level modules in our applications shouldn’t depend on lower-level modules; instead, modules of both levels should depend on Abstractions.

这正是我们在定义IProductRepository. 该ProductService组件是较高级别域层模块的一部分，而IProductRepository实现（我们称之为）是较低级别数据访问模块的一部分。我们不是让我们依赖，而是让两者都依赖抽象。实现抽象，同时使用它。图 3.10说明了这一点。SqlProductRepositoryProductServiceSqlProductRepositoryProductServiceSqlProductRepositoryIProductRepositorySqlProductRepositoryProductService

This is exactly what we did when we defined our IProductRepository. The ProductService component is part of the higher-level domain layer module, whereas the IProductRepository implementation — let’s call it SqlProductRepository — is part of the lower-level data access module. Instead of letting our ProductService depend on SqlProductRepository, we let both ProductService and SqlProductRepository depend on the IProductRepository Abstraction. SqlProductRepository implements the Abstraction, while ProductService uses it. Figure 3.10 illustrates this.

Dependency Inversion Principle和 DI 的关系是，Dependency Inversion Principle规定了我们想要完成什么，DI 说明了我们想要如何完成。该原则并未描述消费者应如何获取其Dependencies。然而，许多开发人员并没有意识到依赖倒置原则的另一个有趣的部分。

The relationship between the Dependency Inversion Principle and DI is that the Dependency Inversion Principle prescribes what we would like to accomplish, and DI states how we would like to accomplish it. The principle doesn’t describe how a consumer should get ahold of its Dependencies. Many developers, however, aren’t aware of another interesting part of the Dependency Inversion Principle.

该原则不仅规定了松散耦合，还规定抽象应该由使用抽象的模块拥有。在这种情况下，“拥有”意味着消费模块可以控制抽象的形状，并且它与该模块一起分发，而不是与实现它的模块一起分发。消费模块应该能够以最有利于自身的方式定义抽象。

Not only does the principle prescribe loose coupling, it states that Abstractions should be owned by the module using the Abstraction. In this context, “owned” means that the consuming module has control over the shape of the Abstraction, and it’s distributed with that module, rather than with the module that implements it. The consuming module should be able to define the Abstraction in a way that benefits itself the most.

您已经看到我们这样做了两次：都是这样定义的。它们的设计方式最适合领域层，尽管它们的实现分别由 UI 和数据访问层负责，如图 3.11所示。IUserContextIProductRepository

You already saw us do this twice: both IUserContext and IProductRepository are defined this way. They’re designed in a way that works best for the domain layer, even though their implementations are the responsibility of the UI and data access layers, respectively, as shown in figure 3.11.

让更高级别的模块或层定义自己的抽象不仅可以防止它必须依赖于较低级别的模块，还可以简化更高级别的模块，因为抽象是根据其特定需求量身定制的。这将我们带回到 BCL 的IPrincipal界面.

Letting a higher-level module or layer define its own Abstractions not only prevents it from having to take a dependency on a lower-level module, it allows the higher-level module to be simplified, because the Abstractions are tailored for its specific needs. This brings us back to the BCL’s IPrincipal interface.

正如我们所描述的，IPrincipal本质上是通用的。相反，依赖倒置原则指导我们定义为应用程序的特殊需求量身定制的抽象。这就是为什么我们定义自己的IUserContext Abstraction而不是让领域层依赖于IPrincipal. 然而，这确实意味着我们必须创建一个适配器实现，允许将调用从这个特定于应用程序的IUserContext 抽象转换为对应用程序框架的调用。

As we described, IPrincipal is generic in nature. The Dependency Inversion Principle instead guides us towards defining Abstractions tailored for our application’s special needs. That’s why we define our own IUserContext Abstraction instead of letting the domain layer depend on IPrincipal. This does mean, however, that we have to create an Adapter implementation that allows translating calls from this application-specific IUserContext Abstraction to calls to the application framework.

如果依赖倒置原则规定抽象应该与它们拥有的模块一起分发，那么领域层IProductService接口是否违反了这个原则？毕竟，IProductService是由UI层消费的，而是由领域层实现的，如图3.12所示。答案是肯定的，这确实违反了依赖倒置原则。

If the Dependency Inversion Principle dictates that Abstractions should be distributed with their owning modules, doesn’t the domain layer IProductService interface violate this principle? After all, IProductService is consumed by the UI layer, but implemented by the domain layer, as figure 3.12 shows. The answer is yes, this does violate the Dependency Inversion Principle.

如果我们热衷于解决这个违规问题，我们应该IProductService离开领域层。然而IProductService，进入 UI 层会使我们的领域层依赖于该层。因为领域层是应用程序的核心部分，我们不希望它依赖于任何其他东西。此外，这种依赖性会使以后无法替换 UI。

If we were keen on fixing this violation, we should move IProductService out of the domain layer. Moving IProductService into the UI layer, however, would make our domain layer dependent on that layer. Because the domain layer is the central part of the application, we don’t want it to depend on anything else. Besides, this dependency would make it impossible to replace the UI later on.

这意味着要解决违规问题，我们的解决方案中需要另外两个额外的项目——一个用于没有Composition Root的独立 UI 层另一个用于 UI 层拥有的IProductService 抽象。然而，出于实用主义，我们选择不为这个示例追求这条路径，因此将违规留在原地。我们希望您能理解我们不想让事情过于复杂。

This means that to fix the violation, we need an additional two extra projects in our solution — one for the isolated UI layer without the Composition Root and another for the IProductService Abstraction that the UI layer owns. Out of pragmatism, however, we chose not to pursuit this path for this example and, therefore, leave the violation in place. We hope you can appreciate that we don’t want to overcomplicate things.

接口还是抽象类？

Interfaces or abstract classes?

许多面向对象的设计指南都将接口作为主要的抽象机制，而 .NET Framework 设计指南认可抽象类优于接口。⁹  你应该使用接口还是抽象类？关于 DI，令人放心的答案是这无关紧要。重要的部分是您针对某种抽象进行编程。

Many guides to object-oriented design focus on interfaces as the main abstraction mechanism, whereas the .NET Framework Design Guidelines endorse abstract classes over interfaces.⁹  Should you use interfaces or abstract classes? With relation to DI, the reassuring answer is that it doesn’t matter. The important part is that you program against some sort of abstraction.

在其他情况下，在接口和抽象类之间进行选择很重要，但在这里不重要。您会注意到我们可以互换使用这些词；我们经常使用术语抽象来涵盖接口和抽象类。这并不意味着作为作者，我们对其中一个没有偏爱。事实上，我们有。在编写应用程序时，我们通常更喜欢接口而不是抽象类，原因如下：

Choosing between interfaces and abstract classes is important in other contexts, but not here. You’ll notice that we use these words interchangeably; we often use the term Abstraction to encompass both interfaces and abstract classes. This doesn’t mean that we, as authors, don’t have a preference for one over the other. We do, in fact. When it comes to writing applications, we typically prefer interfaces over abstract classes for these reasons:

• 抽象类很容易被滥用为基类。基类可以很容易地变成不断变化、不断增长的上帝对象. ¹⁰  派生类与其基类紧密耦合，当基类包含Volatile行为时，这会成为一个问题。另一方面，接口迫使我们进入“组合优于继承”的口头禅。¹¹ 
• Abstract classes can easily be abused as base classes. Base classes can easily turn into ever-changing, ever-growing God Objects.¹⁰  The derivatives are tightly coupled to its base class, which can become a problem when the base class contains Volatile behavior. Interfaces, on the other hand, force us into the “Composition over Inheritance” mantra.¹¹ 

• 具体类可以实现多个接口，尽管在 .NET 中，这些接口只能从单个基类派生。使用接口作为抽象的载体更加灵活。
• Concrete classes can implement several interfaces, although in .NET, those can only derive from a single base class. Using interfaces as the vehicle of Abstraction is more flexible.
• 与抽象类相比，C# 中的接口定义没有那么笨拙。对于接口，我们可以省略其成员中的和关键字。这使得接口的定义更加简洁。abstractpublic
• Interface definitions in C# are less clumsy compared to abstract classes. With interfaces, we can omit the abstract and public keywords from their members. This makes an interface a more succinct definition.

然而，在编写可重用库时，由于需要处理向后兼容性，这个主题变得不那么明确了。从这个角度来看，抽象类可能更有意义，因为可以在以后添加非抽象成员，而将成员添加到接口是一个重大变化。这就是 .NET Framework 设计指南更喜欢抽象类的原因。

When writing reusable libraries, however, the subject is becoming less clear-cut, due to the need to deal with backward compatibility. In that light, an abstract class might make more sense because non-abstract members can be added later, whereas adding members to an interface is a breaking change. That’s why the .NET Framework Design Guidelines prefer abstract classes.

现在让我们转到数据访问层。我们将为先前定义的IProductRepository接口创建一个实现。

Now let’s move on to the data access layer. We’ll create an implementation for the previously defined IProductRepository interface.

3.1.3 构建新的数据访问层

3.1.3 Building a new data access layer

像 Mary 一样，我们希望使用 Entity Framework Core 来实现我们的数据访问层，因此我们按照她在第 2 章中执行的相同步骤来创建实体模型。主要区别在于现在只是数据访问层的一个实现细节，而不是整个数据访问层。CommerceContext

Like Mary, we’d like to implement our data access layer using Entity Framework Core, so we follow the same steps she did in chapter 2 to create the Entity model. The main difference is that CommerceContext is now only an implementation detail of the data access layer, as opposed to being the entirety of the data access layer.

在此模型中，数据访问层之外的任何内容都不会知道或依赖实体框架。它可以在没有任何上游影响的情况下被换出。考虑到这一点，我们可以创建.IProductRepository

In this model, nothing outside of the data access layer will have any awareness of, or dependency on, Entity Framework. It can be swapped out without any upstream effects. With that in mind, we can create an implementation of IProductRepository.

清单 3.10IProductRepository使用 Entity Framework Core 实现

Listing 3.10 Implementing IProductRepository using Entity Framework Core

public class SqlProductRepository : IProductRepository
{
    private readonly CommerceContext context;

    public SqlProductRepository(CommerceContext context)
    {
        if (context == null) throw new ArgumentNullException("context");

        this.context = context;
    }

    public IEnumerable<Product> GetFeaturedProducts()
    {
        return
            from product in this.context.Products
            where product.IsFeatured
            select product;
    }
}

在 Mary 的应用程序中，Product 实体也被用作域对象，尽管它是在数据访问层中定义的。这已不再是这种情况。该类Product现在已在我们的领域层中定义。我们的数据访问层重用了Product类从那层。

In Mary’s application, the Product Entity was also used as a domain object, although it was defined in the data access layer. This is no longer the case. The Product class is now defined in our domain layer. Our data access layer reuses the Product class from that layer.

为简单起见，我们选择让数据访问层重用我们的领域对象，而不是定义自己的实现。我们之所以能够这样做，是因为 Entity Framework Core 允许我们编写无持久性的实体。¹²  这是否是一种合理的做法在很大程度上取决于域对象的结构和复杂性。如果我们后来得出结论，这个共享模型正在对我们的模型强制执行不需要的约束，我们可以通过引入内部持久性对象来更改我们的数据访问层，而无需触及应用程序的其余部分。在那种情况下，我们需要数据访问层将那些内部持久性对象转换为域对象。

For simplicity, we chose to let the data access layer reuse our domain object instead of defining its own implementation. We were able to do so because Entity Framework Core allows us to write Entities that are persistence ignorant.¹²  Whether this is a reasonable practice depends a lot on the structure and complexity of your domain objects. If we later conclude that this shared model is enforcing unwanted constraints on our model, we can change our data access layer by introducing internal persistence objects, without touching the rest of the application. In that case, we’d need the data access layer to convert those internal persistence objects into domain objects.

在上一章中，我们讨论了 MaryCommerceContext对连接字符串的隐式依赖是如何导致她一路走来的问题的。我们的 newCommerceContext将使这种依赖关系显式化，这是与 Mary 的实现的另一个偏差。下一个清单显示了我们的新CommerceContext.

In the previous chapter, we discussed how the implicit dependency of Mary’s CommerceContext on the connection string caused her problems along the way. Our new CommerceContext will make this dependency explicit, which is another deviation from Mary’s implementation. The next listing shows our new CommerceContext.

清单 3.11 一个更好的CommerceContext类

Listing 3.11 A better CommerceContext class

public class CommerceContext : DbContext
{
    private readonly string connectionString;

    public CommerceContext(string connectionString)    ①  
    {
        if (string.IsNullOrWhiteSpace(connectionString))
            throw new ArgumentException(
                "connectionString should not be empty.",
                "connectionString");

        this.connectionString = connectionString;    ②  
    }

    public DbSet<Product> Products { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder builder)
    {
        builder.UseSqlServer(this.connectionString);
    }
}

这几乎让我们结束了电子商务应用程序的重新实现。唯一仍然缺少的实现是IUserContext.

This almost brings us to the end of our re-implementation of the e-commerce application. The only implementation still missing is that of IUserContext.

3.1.4 实现特定于 ASP.NET Core 的IUserContext适配器

3.1.4 Implementing an ASP.NET Core–specific IUserContext Adapter

缺少的最后一个具体实现是. 在 Web 应用程序中，有关发出请求的用户的信息通常会随每个请求一起传递到服务器。此信息使用 cookie 或 HTTP 标头进行中继。我们如何检索当前用户的身份在很大程度上取决于我们使用的框架。这意味着我们在构建 ASP.NET Core 应用程序时需要完全不同的实现，例如与 Windows 服务相比。IUserContext

The last concrete implementation missing is that of IUserContext. In web applications, information about a user who issues a request is usually passed on to the server with each request. This information is relayed using cookies or HTTP headers. How we retrieve the identity of the current user is highly dependent on the framework we use. This means that we’ll need a completely different implementation when building an ASP.NET Core application compared with, for instance, a Windows service.

我们的实施IUserContext是特定于框架的。我们不希望我们的领域层和数据层都知道有关应用程序框架的任何信息。这将使得无法在不同的上下文中使用这些层。我们需要在其他地方实施。因此，UI 层是我们IUserContext实现的理想场所。

The implementation of our IUserContext is framework specific. We want neither our domain layer nor our data layer to know anything about the application framework. That would make it impossible to use those layers in a different context. We need to implement this elsewhere. The UI layer, therefore, is an ideal place for our IUserContext implementation.

以下清单显示了IUserContextASP.NET Core 应用程序的可能实现。

The following listing shows a possible IUserContext implementation for an ASP.NET Core application.

ASP.NET Core 的清单 3.12 IUserContext实现

Listing 3.12 IUserContext implementation for ASP.NET Core

public class AspNetUserContextAdapter : IUserContext
{
    private static HttpContextAccessor Accessor = new HttpContextAccessor();

    public bool IsInRole(Role role)
    {
        return Accessor.HttpContext.User.IsInRole(role.ToString());
    }
}

AspNetUserContextAdapter需要一个工作。，一个由 ASP.NET Core 框架指定的组件，允许访问当前请求的 ，就像我们能够在 ASP.NET “经典”中使用. 我们用来访问有关当前用户的请求信息。HttpContextAccessorHttpContextAccessorHttpContextHttpContext.CurrentHttpContext

AspNetUserContextAdapter requires an HttpContextAccessor to work. HttpContextAccessor, a component specified by the ASP.NET Core framework, allows access to the HttpContext of the current request, like we were able to in ASP.NET “classic” using HttpContext.Current. We use HttpContext to access the request’s information about the current user.

AspNetUserContextAdapter使我们特定于应用程序的IUserContext 抽象适应ASP.NET Core API。此类是我们在第 1 章中讨论的适配器设计模式的实现。¹³ 

AspNetUserContextAdapter adapts our application-specific IUserContext Abstraction to the ASP.NET Core API. This class is an implementation of the Adapter design pattern that we discussed in chapter 1.¹³ 

实施后，我们对AspNetUserContextAdapter电子商务应用程序的重新实施就完成了。这将我们带到了Composition Root。

With AspNetUserContextAdapter implemented, our reimplementation of the e-commerce application is finished. This brings us to our Composition Root.

3.1.5 在Composition Root中组合应用

3.1.5 Composing the application in the Composition Root

有了,和实现后，我们现在可以设置 ASP.NET Core MVC 来构建 的实例，其中由一个实例提供，该实例本身是使用一个和一个. 这最终会产生如下所示的对象图。ProductServiceSqlProductRepositoryAspNetUserContextAdapterHomeControllerHomeControllerProductServiceSqlProductRepositoryAspNetUserContextAdapter

With ProductService, SqlProductRepository and AspNetUserContextAdapter implemented, we can now set up ASP.NET Core MVC to construct an instance of HomeController, where HomeController is fed by a ProductService instance, which itself is constructed using a SqlProductRepository and an AspNetUserContextAdapter. This eventually results in an object graph that would look as follows.

清单 3.13 应用程序的对象图

Listing 3.13 The application’s object graph

new HomeController(
    new ProductService(
        new SqlProductRepository(
            new CommerceContext(connectionString)),
        new AspNetUserContextAdapter()));

我们将在第 7 章中更详细地讨论如何将此类对象图的构造插入到 ASP.NET Core 框架中，因此我们不会在这里展示。但现在一切都正确连接在一起，我们可以浏览到应用程序的主页并获得如图 3.13所示的页面。

We’ll discuss how the construction of such an object graph is plugged into the ASP.NET Core framework in greater detail in chapter 7, so we won’t show that here. But now that everything is correctly wired together, we can browse to the application’s homepage and get the page shown in figure 3.13.

3.2 分析松耦合实现

3.2 Analyzing the loosely coupled implementation

上一节包含很多细节，因此如果您一路上看不到大局也就不足为奇了。在本节中，我们将尝试从更广泛的角度解释发生的事情。

The previous section contained lots of details, so it’s hardly surprising if you lost sight of the big picture along the way. In this section, we’ll try to explain what happened in broader terms.

3.2.1 理解组件之间的交互

3.2.1 Understanding the interaction between components

每一层中的类直接或以抽象形式相互交互。它们跨模块边界这样做，因此很难了解它们是如何交互的。图 3.14显示了不同的依赖关系如何交互，对图 3.4中描述的原始大纲进行了更详细的概述。

The classes in each layer interact with each other either directly or in abstract form. They do so across module boundaries, so it can be difficult to follow how they interact. Figure 3.14 shows how the different Dependencies interact, giving a more detailed overview to the original outline described in figure 3.4.

当应用程序启动时，中的代码Startup创建一个新的自定义控制器激活器并从应用程序的配置文件中查找连接字符串。当页面请求进来时，应用程序调用Create控制器激活器。

When the application starts, the code in Startup creates a new custom controller activator and looks up the connection string from the application’s configuration file. When a page request comes in, the application invokes Create on the controller activator.

激活器将存储的连接字符串提供给新的实例（图中未显示）。它注入一个新的实例。反过来，实例连同的实例（图中未显示）被注入到新的实例中。同样，被注入到 的新实例中，然后从该方法返回。CommerceContextCommerceContextSqlProductRepositorySqlProductRepositoryAspNetUserContextAdapterProductServiceProductServiceHomeControllerCreate

The activator supplies the stored connection string to a new instance of CommerceContext (not shown in the diagram). It injects CommerceContext into a new instance of SqlProductRepository. In turn, the SqlProductRepository instance together with an instance of AspNetUserContextAdapter (not shown in the diagram) are injected into a new instance of ProductService. Similarly, ProductService is injected into a new instance of HomeController, which is then returned from the Create method.

然后 ASP.NET Core MVC 框架调用实例Index上的方法HomeController，使其调用实例GetFeaturedProducts上的方法。这又会调用实例上的方法。最后，填充后的 返回，MVC 找到并呈现正确的视图。ProductRepositoryGetFeaturedProductsSqlProductRepositoryViewResultFeaturedProductsViewModel

The ASP.NET Core MVC framework then invokes the Index method on the HomeController instance, causing it to invoke the GetFeaturedProducts method on the ProductRepository instance. This in turn calls the GetFeaturedProducts method on the SqlProductRepository instance. Finally, the ViewResult with the populated FeaturedProductsViewModel is returned, and MVC finds and renders the correct view.

3.2.2 分析新的依赖图

3.2.2 Analyzing the new dependency graph

在 2.2 节中，您了解了依赖关系图如何帮助您分析和理解架构实现所提供的灵活性程度。DI 是否更改了应用程序的依赖关系图？

In section 2.2, you saw how a dependency graph can help you analyze and understand the degree of flexibility provided by the architectural implementation. Has DI changed the dependency graph for the application?

图 3.15显示依赖图确实发生了变化。领域模型不再有任何依赖关系，可以作为一个独立的模块。另一方面，数据访问层现在有了依赖；在玛丽的申请中，它没有。

Figure 3.15 shows that the dependency graph has indeed changed. The domain model no longer has any dependencies and can act as a standalone module. On the other hand, the data access layer now has a dependency; in Mary’s application, it had none.

图 3.15中需要注意的最重要的事情是领域层不再有任何依赖关系。这应该提高我们的希望，我们这次可以更有利地回答有关可组合性的原始问题（参见第 2.2 节）：

The most important thing to note in figure 3.15 is that the domain layer no longer has any dependencies. This should raise our hopes that we can answer the original questions about composability (see section 2.2) more favorably this time:

• 我们可以更换基于网络的用户界面吗使用基于 WPF 的 UI？这在以前是可能的，并且在新设计中仍然是可能的。域模型库和数据访问库都不依赖于基于 Web 的 UI，因此我们可以轻松地在其位置放置其他内容。
• Can we replace the web-based UI with a WPF-based UI? That was possible before and is still possible with the new design. Neither the domain model library nor the data access library depends on the web-based UI, so we can easily put something else in its place.
• 我们能否将关系数据访问层替换为与 Azure 表服务一起使用的层？？在后面的章节中，我们将描述应用程序如何定位和实例化正确的，因此，现在，从表面上看：数据访问层正在通过后期绑定加载，并且类型名称被定义为应用程序在应用程序的配置文件中设置。可以抛弃当前的数据访问层并注入一个新的，只要它还提供.IProductRepositoryIProductRepository
• Can we replace the relational data access layer with one that works with the Azure Table Service? In a later chapter, we’ll describe how the application locates and instantiates the correct IProductRepository, so, for now, take the following at face value: the data access layer is being loaded by late binding, and the type name is defined as an application setting in the application’s configuration file. It’s possible to throw the current data access layer away and inject a new one, as long as it also provides an implementation of IProductRepository.

本章中描述的示例电子商务应用程序只向我们展示了有限的复杂程度：只读场景中只涉及一个存储库。到目前为止，我们一直保持应用程序尽可能简单和小巧，以温和地介绍一些核心概念和原则。因为 DI 的主要目的之一是管理复杂性，所以我们需要一个复杂的应用程序来充分领会它的力量。在本书的学习过程中，我们将扩展示例电子商务应用程序以充分展示 DI 的不同方面。

The sample e-commerce application described in this chapter only presents us with a limited level of complexity: there’s only a single Repository involved in a read-only scenario. Until now, we’ve kept the application as simple and small as possible to gently introduce some core concepts and principles. Because one of the main purposes of DI is to manage complexity, we need a complex application to fully appreciate its power. During the course of the book, we’ll expand the sample e-commerce application to fully demonstrate different aspects of DI.

本章结束了本书的第一部分。第 1 部分的目的是让 DI 广为人知，并从总体上介绍 DI。在本章中，您看到了构造函数注入的示例。我们还介绍了Method Injection和Composition Root作为与 DI 相关的模式。在下一章中，我们将深入探讨这些和其他设计模式。

This chapter concludes the first part of the book. The purpose of part 1 was to put DI on the map and to introduce DI in general. In this chapter, you’ve seen examples of Constructor Injection. We also introduced Method Injection and Composition Root as patterns related to DI. In the next chapter, we’ll dive deeper into these and other design patterns.

概括

Summary

• 将现有应用程序重构为更易于维护、松散耦合的设计是很困难的。另一方面，大的重写通常风险更大且成本更高。
• Refactoring existing applications towards a more maintainable, loosely coupled design is hard. Big rewrites, on the other hand, are often riskier and expensive.
• 使用视图模型可以简化视图，因为传入的数据是专门为视图设计的。
• The use of view models can simplify the view, because the incoming data is shaped specifically for the view.
• 因为视图更难测试，所以视图越笨越好。它还简化了可能处理视图的 UI 设计人员的工作。
• Because views are harder to test, the dumber the view, the better. It also simplifies the work of a UI designer who might work on the view.
• 当您限制域层内易失性依赖项的数量时，您将获得更高程度的解耦、重用和可测试性。
• When you limit the amount of Volatile Dependencies within the domain layer, you get a higher degree of decoupling, reuse, and Testability.
• 在构建应用程序时，由外而内的方法有助于更快速地制作原型，从而缩短反馈周期。
• When building applications, the outside-in approach facilitates more rapid prototyping, which can shorten the feedback cycle.
• 当您希望在应用程序中实现高度模块化时，您需要应用构造函数注入模式并在靠近应用程序入口点的组合根中构建对象图。
• When you want a high degree of modularity in your application, you need to apply the Constructor Injection pattern and build object graphs in the Composition Root, which is located close to the application’s entry point.
• 接口编程是 DI 的基石。它允许您替换、模拟和拦截依赖项，而无需对其使用者进行更改。当实现和抽象放在不同的程序集中时，它可以替换整个库。
• Programming to interfaces is a cornerstone of DI. It allows you to replace, mock, and Intercept a Dependency, without having to make changes to its consumers. When implementation and Abstraction are placed in different assemblies, it enables whole libraries to be replaced.
• 接口编程并不意味着所有的类都应该实现一个接口。实体、视图模型和 DTO等短期对象通常不包含需要模拟、拦截、修饰或替换的行为。
• Programming to interfaces doesn’t mean that all classes should implement an interface. Short-lived objects, such as Entities, view models, and DTOs, typically contain no behavior that requires mocking, Interception, decoration, or replacement.
• 对于 DI，使用接口还是纯抽象类都没有关系。从一般开发的角度来看，作为作者，我们通常更喜欢接口而不是抽象类。
• With respect to DI, it doesn’t matter whether you use interfaces or purely abstract classes. From a general development perspective, as authors, we typically prefer interfaces over abstract classes.
• 可重用库是具有在编译时未知的客户端的库。可重用库通常通过 NuGet 提供。只有同一 (Visual Studio) 解决方案中的调用方的库不被视为可重用库。
• A reusable library is a library that has clients that aren’t known at compile time. Reusable libraries are typically shipped via NuGet. Libraries that only have callers within the same (Visual Studio) solution aren’t considered to be reusable libraries.
• DI 与依赖倒置原则密切相关。这个原则意味着你应该针对接口进行编程，并且一个层必须控制它使用的接口。
• DI is closely related to the Dependency Inversion Principle. This principle implies that you should program against interfaces, and that a layer must be in control over the interfaces it uses.
• 使用DI 容器有助于使应用程序的组合根更易于维护，但它不会神奇地使紧密耦合的代码松散耦合。为了使应用程序变得可维护，必须在设计时考虑到 DI 模式和技术。
• The use of a DI Container can help in making the application’s Composition Root more maintainable, but it won’t magically make tightly coupled code loosely coupled. For an application to become maintainable, it must be designed with DI patterns and techniques in mind.

P第 1 条概述了 DI，讨论了 DI 的目的和好处。尽管第 3 章包含了一个广泛的示例，但我们确信第一章仍然给您留下了一些未解决的问题。在第 2 部分中，我们将更深入地挖掘以回答其中的一些问题。

Part 1 provided an overview of DI, discussing the purpose and benefits of DI. Even though chapter 3 contained an extensive example, we’re sure the first chapters still left you with some unresolved questions. In part 2, we’ll dig a little deeper to answer some of those questions.

正如标题所暗示的，第 2 部分提供了模式、反模式和代码味道的完整目录。有些人不喜欢设计模式，因为他们觉得它们枯燥或过于抽象。就个人而言，我们喜欢模式，因为它们为我们提供了一种高级语言，使我们在讨论软件设计时更加高效和简洁。我们的目的是使用这个目录为 DI 提供一种模式语言。尽管模式描述必须包含一些概括，但我们使用示例使每个模式具体化。您可以按顺序阅读所有三章，但目录中的每个项目也都已写好，以便您可以单独阅读。

As the title implies, part 2 presents a complete catalog of patterns, anti-patterns, and code smells. Some people dislike design patterns, because they find them dry or too abstract. Personally, we love patterns, because they provide us with a high-level language that makes us more efficient and concise when we discuss software design. It’s our intent to use this catalog to provide a pattern language for DI. Although a pattern description must contain some generalizations, we’ve made each pattern concrete, using examples. You can read all three chapters in sequence, but each item in the catalog is also written so that you can read it by itself.

第 4 章包含 DI 设计模式的迷你目录。从某种意义上说，这些模式构成了有关如何实施 DI 的规范性指导，但您应该知道，我们并不认为它们具有同等重要性。Constructor Injection和Composition Root是迄今为止最重要的设计模式，而所有其他模式应视为可以在特殊情况下应用的边缘案例。

Chapter 4 contains a mini catalog of DI design patterns. In a sense, these patterns constitute prescriptive guidance on how to implement DI, but you should be aware that we don’t consider them to be of equal importance. Constructor Injection and Composition Root are by far the most important design patterns, whereas all the other patterns should be treated as fringe cases that can be applied in specialized circumstances.

第 4 章为您提供了一组通用的解决方案，而第 5 章包含了一系列应避免的情况。这些反模式描述了解决典型 DI 挑战的常见但不正确的方法。在每种情况下，反模式都描述了如何识别事件以及如何解决问题。了解和理解这些反模式对于避免它们所代表的陷阱非常重要，而且正如第 4 章介绍的两个最重要的模式一样，最重要的反模式是Service Locator，它是 DI 的对立面。

Whereas chapter 4 gives you a set of generalized solutions, chapter 5 contains a catalog of situations to avoid. These anti-patterns describe common, but incorrect ways to address typical DI challenges. In each case, the anti-pattern describes how to identify occurrences and how to resolve the issue. It’s important to know and understand these anti-patterns to avoid the traps that they represent, and, just as chapter 4 presents two dominatingly important patterns, the most important anti-pattern is Service Locator, the antithesis of DI.

当您将 DI 应用于现实生活中的编程任务时，您会遇到一些挑战。我们认为我们都曾有过怀疑自己是否理解某个工具的时刻或技术，但我们认为，“理论上，这可能有效，但我的情况很特殊。” 当我们发现自己有这样的想法时，我们很清楚我们还有更多东西要学。

As you apply DI to real-life programming tasks, you’ll run into some challenges. We think we’ve all had moments of doubt where we feel that we understand a tool or technique, and yet we think, “In theory, this may work, but my case is special.” When we find ourself thinking like this, it’s clear to us that we have more to learn.

在我们的职业生涯中，我们看到了一组特定的问题一再出现。这些问题中的每一个都有一个通用的解决方案，您可以将您的代码应用到第 4 章中的一种 DI 模式。第 6 章包含这些常见问题或代码异味及其相应解决方案的目录。

During our career, we’ve seen a particular set of problems appear again and again. Each of these problems has a general solution you can apply to move your code towards one of the DI patterns from chapter 4. Chapter 6 contains a catalog of these common problems, or code smells, and their corresponding solutions.

我们希望这是本书中最有用的部分，因为它最经久不衰。希望您在第一次阅读这些章节数月甚至数年之后能够再次阅读这些章节。

We expect this to be the most useful part of the book, because it’s the most enduring. Hopefully, you’ll return to these chapters months and even years after you first read them.

在这一章当中

In this chapter

• 使用Composition Root组合对象图
• Composing object graphs with Composition Root
• 使用构造函数注入静态声明所需的依赖项
• Statically declaring required Dependencies with Constructor Injection
• 使用方法注入将依赖项传递到组合根之外
• Passing Dependencies outside the Composition Root with Method Injection
• 使用属性注入声明可选依赖项
• Declaring optional Dependencies with Property Injection
• 了解要使用的模式
• Understanding which pattern to use

像所有专业人士一样，厨师有自己的行话，使他们能够用一种对我们其他人来说通常听起来深奥的语言来交流复杂的食物准备工作。他们使用的大多数术语都基于法语（除非您已经会说法语），这无济于事。酱汁是厨师使用专业术语的一个很好的例子。在第 1 章中，我们简要讨论了sauce béarnaise，但没​​有详细说明围绕它的分类法。

Like all professionals, cooks have their own jargon that enables them to communicate about complex food preparation in a language that often sounds esoteric to the rest of us. It doesn’t help that most of the terms they use are based on the French language (unless you already speak French, that is). Sauces are a great example of the way cooks use their professional terminology. In chapter 1, we briefly discussed sauce béarnaise, but we didn’t elaborate on the taxonomy that surrounds it.

蛋黄酱实际上是一种荷兰酱，其中柠檬汁被减少的醋、青葱、山萝卜和龙蒿所取代。其他酱料是基于酱汁荷兰酱，包括马克最喜欢的酱汁慕斯林，它是将打发的奶油倒入荷兰酱中制成的。

A sauce béarnaise is really a sauce hollandaise where the lemon juice is replaced by a reduction of vinegar, shallots, chervil, and tarragon. Other sauces are based on sauce hollandaise, including Mark’s favorite, sauce mousseline, which is made by folding whipped cream into the hollandaise.

你注意到行话了吗？我们没有说“小心地将生奶油混合到酱汁中，注意不要使其塌陷”，而是使用了折叠这个词. 我们没有说“加厚和加强醋的味道”，而是使用了减少这个词。行话使您能够简洁有效地进行交流。

Did you notice the jargon? Instead of saying, “carefully mix the whipped cream into the sauce, taking care not to collapse it,” we used the term folding. Instead of saying, “thickening and intensifying the flavor of vinegar,” we used the term reduction. Jargon allows you to communicate concisely and effectively.

在软件开发中，我们有一套复杂而难以理解的行话。您可能不知道烹饪术语bain-marie指的是什么，但我们敢肯定，如果您告诉大多数厨师“字符串是不可变的类，它表示 Unicode 字符的序列”，他们会完全不知所措。当谈到如何构建代码来解决特定类型的问题时，我们有为常见解决方案命名的设计模式。就像sauce hollandaise和fold这两个术语帮助我们简洁地交流如何制作sauce mousseline一样，设计模式帮助我们谈论代码的结构。

In software development, we have a complex and impenetrable jargon of our own. You may not know what the cooking term bain-marie refers to, but we’re pretty sure most chefs would be utterly lost if you told them that “strings are immutable classes, which represent sequences of Unicode characters.” And when it comes to talking about how to structure code to solve particular types of problems, we have design patterns that give names to common solutions. In the same way that the terms sauce hollandaise and fold help us succinctly communicate how to make sauce mousseline, design patterns help us talk about how code is structured.

在前面的章节中，我们已经命名了很多软件设计模式。例如，在第 1 章中我们讨论了模式抽象工厂、空对象、装饰器、组合、适配器、保护子句、存根、模拟和假。虽然此时您可能无法回忆起它们中的每一个，但如果我们谈论设计模式，您可能不会感到那么不舒服。我们人类喜欢命名重复出现的模式，即使它们很简单。

We’ve already named quite a few software design patterns in the previous chapters. For instance, in chapter 1 we talked about the patterns Abstract Factory, Null Object, Decorator, Composite, Adapter, Guard Clause, Stub, Mock, and Fake. Although, at this point, you might not be able to recall each of them, you probably won’t feel that uncomfortable if we talk about design patterns. We human beings like to name reoccurring patterns, even if they’re simple.

如果您对设计模式的一般了解有限，请不要担心。设计模式的主要目的是提供对实现目标的特定方式的详细且独立的描述——如果您愿意的话，也可以是配方。此外，您已经看到了我们将在本章中描述的四种基本 DI 设计模式中的三种示例：

Don’t worry if you have only a limited knowledge of design patterns in general. The main purpose of a design pattern is to provide a detailed and self-contained description of a particular way of attaining a goal — a recipe, if you will. And besides, you already saw examples of three out of the four basic DI design patterns that we’ll describe in this chapter:

• Composition Root——描述你应该在哪里以及如何组合应用程序的对象图。
• Composition Root — Describes where and how you should compose an application’s object graphs.
• 构造函数注入——允许类静态声明其所需的依赖项。
• Constructor Injection — Allows a class to statically declare its required Dependencies.
• 方法注入——当依赖项或消费者可能因每个操作而改变，使您能够向消费者提供依赖项。
• Method Injection — Enables you to provide a Dependency to a consumer when either the Dependency or the consumer might change for each operation.
• 属性注入- 允许客户端有选择地覆盖某些类的默认行为，其中此默认行为在Local Default中实现。
• Property Injection — Allows clients to optionally override some class’s default behavior, where this default behavior is implemented in a Local Default.

本章的结构是提供模式目录。对于每个模式，我们将提供简短描述、代码示例、优点和缺点等。您可以按顺序阅读本章介绍的所有四种模式，也可以只阅读您感兴趣的模式。最重要的模式是Composition Root和Constructor Injection，您应该在大多数情况下使用它们——其他模式随着章节的进行变得更加专业。

This chapter is structured to provide a catalog of patterns. For each pattern, we’ll provide a short description, a code example, advantages and disadvantages, and so on. You can read about all four patterns introduced in this chapter in sequence or only read the ones that interest you. The most important patterns are Composition Root and Constructor Injection, which you should use in most situations — the other patterns become more specialized as the chapter progresses.

4.1 组合根

4.1 Composition Root

当您从许多松散耦合的类创建应用程序时，组合应该尽可能靠近应用程序的入口点进行。该Main方法是大多数应用程序类型的入口点。Composition Root组成对象图，随后执行应用程序的实际工作。

When you’re creating an application from many loosely coupled classes, the composition should take place as close to the application’s entry point as possible. The Main method is the entry point for most application types. The Composition Root composes the object graph, which subsequently performs the actual work of the application.

在上一章中，您看到大多数类都使用构造函数注入。通过这样做，他们将创建依赖项的责任推给了消费者。然而，这样的消费者也推动了创建他们的依赖关系的责任取决于他们的消费者。

In the previous chapter, you saw that most classes used Constructor Injection. By doing so, they pushed the responsibility for the creation of their Dependencies up to their consumers. Such consumers, however, also pushed the responsibility for creating their Dependencies up to their consumers.

您不能无限期地延迟对象的创建。必须有一个位置供您创建对象图。您应该将此创建集中到应用程序的单个区域中。这个地方叫做Composition Root。

You can’t delay the creation of your objects indefinitely. There must be a location where you create your object graphs. You should concentrate this creation into a single area of your application. This place is called the Composition Root.

在上一章中，这导致了您在清单 3.13（图 4.1）中看到的对象图。此清单还显示来自所有应用程序层的所有组件都在Composition Root中构建。

In the previous chapter, this resulted in the object graph that you saw in listing 3.13 (figure 4.1). This listing also shows that all components from all application layers are constructed in the Composition Root.

清单 4.1 来自第 3 章的应用程序对象图

Listing 4.1 The application’s object graph from chapter 3

new HomeController(    ①  
    new ProductService(    ②  
        new SqlProductRepository(    ③  
            new CommerceContext(connectionString)),  ③  
        new AspNetUserContextAdapter()));    ④  

如果您有一个控制台应用程序是为在这个特定的对象图上运行而编写的，它可能看起来如下面的清单所示。

If you were to have a console application that was written to operate on this particular object graph, it might look as shown in the following listing.

清单 4.2 作为控制台应用程序一部分的应用程序对象图

Listing 4.2 The application’s object graph as part of a console application

public static class Program
{
    public static void Main(string[] args)    ①  
    {
        string connectionString = args[0];    ②  

        HomeController controller =
            CreateController(connectionString);    ③  

        var result = controller.Index();

        var vm = (FeaturedProductsViewModel)result.Model;

        Console.WriteLine("Featured products:");

        foreach (var product in vm.Products)
        {
            Console.WriteLine(product.SummaryText);
        }
    }

    private static HomeController CreateController(    ④  
        string connectionString)
    {
        var userContext = new ConsoleUserContext();    ⑤  

        return
            new HomeController(    ⑥  
                new ProductService(    ⑥  
                    new SqlProductRepository(    ⑥  
                        new CommerceContext(    ⑥  
                            connectionString)),    ⑥  
                    userContext));    ⑥  
    }
}

在此示例中，Composition RootMain与方法分离. 然而，这不是必需的 — Composition Root不是方法或类，它是一个概念。它可以是Main方法的一部分，也可以跨越多个类，只要它们都驻留在一个模块中即可。将其分离到自己的方法中有助于确保组合得到巩固，并且不会以其他方式散布在后续的应用程序逻辑中。

In this example, the Composition Root is separated from the Main method. This isn’t required, however — the Composition Root isn’t a method or a class, it’s a concept. It can be part of the Main method, or it can span multiple classes, as long as they all reside in a single module. Separating it into its own method helps to ensure that the composition is consolidated and not otherwise interspersed with subsequent application logic.

4.1.1 Composition Root 的工作原理

4.1.1 How Composition Root works

当您编写松散耦合的代码时，您会创建许多类来创建一个应用程序。在许多不同的位置组合这些类以创建小型子系统可能很诱人，但这限制了您拦截的能力那些系统来修改他们的行为。相反，您应该在应用程序的一个区域中组合类。

When you write loosely coupled code, you create many classes to create an application. It can be tempting to compose these classes at many different locations in order to create small subsystems, but that limits your ability to Intercept those systems to modify their behavior. Instead, you should compose classes in one single area of your application.

当您孤立地看待构造函数注入时，您可能会想，它不会将选择依赖关系的决定推迟到另一个地方吗？是的，确实如此，这是一件好事。这意味着您将获得一个可以连接协作类的中心位置。

When you look at Constructor Injection in isolation, you may wonder, doesn’t it defer the decision about selecting a Dependency to another place? Yes, it does, and that’s a good thing. This means that you get a central place where you can connect collaborating classes.

Composition Root充当第三方，将消费者与其服务联系起来。你推迟决定如何连接课程的时间越长，你的选择就越多。因此，Composition Root应放置在尽可能靠近应用程序入口点的位置。

The Composition Root acts as a third party that connects consumers with their services. The longer you defer the decision on how to connect classes, the more you keep your options open. Thus, the Composition Root should be placed as close to the application’s entry point as possible.

即使是使用松散耦合和后期绑定来组合自身的模块化应用程序也有一个包含应用程序入口点的根。示例如下：

Even a modular application that uses loose coupling and late binding to compose itself has a root that contains the entry point into the application. Examples follow:

• .NET Core 控制台应用程序是一个包含Program类的库 (.dll)用一种Main方法。
• A .NET Core console application is a library (.dll) containing a Program class with a Main method.
• 一个 ASP.NET Core Web 应用程序也是一个包含带有方法的Program类的库Main.
• An ASP.NET Core web application also is a library containing a Program class with a Main method.
• UWP和 WPF 应用程序是可执行文件(.exe) 与 App.xaml.cs 文件。
• UWP and WPF applications are executables (.exe) with an App.xaml.cs file.

存在许多其他技术，但它们有一个共同点：一个模块包含应用程序的入口点——这是应用程序的根。不要误以为Composition Root是 UI 层的一部分。即使您将Composition Root放置在与 UI 层相同的程序集中，正如我们将在下一个示例中所做的那样，Composition Root也不是该层的一部分。

Many other technologies exist, but they have one thing in common: one module contains the entry point of the application — this is the root of the application. Don’t be misled into thinking that the Composition Root is part of your UI layer. Even if you place the Composition Root in the same assembly as your UI layer, as we’ll do in the next example, the Composition Root isn’t part of that layer.

程序集是一个部署工件：您将代码拆分为多个程序集以允许单独部署代码。另一方面，架构层是逻辑工件：您可以将多个逻辑工件组合在一个部署工件中。尽管包含组合根和 UI 层的程序集依赖于系统中的所有其他模块，但 UI 层本身并不依赖。

Assemblies are a deployment artifact: you split code into multiple assemblies to allow code to be deployed separately. An architectural layer, on the other hand, is a logical artifact: you can group multiple logical artifacts in a single deployment artifact. Even though the assembly that holds both the Composition Root and the UI layer depends on all other modules in the system, the UI layer itself doesn’t.

不需要将Composition Root放置在与 UI 层相同的项目中。您可以将 UI 层移出应用程序的根项目。这样做的好处是你可以防止拥有 UI 层的项目产生依赖（例如，第 3 章中的数据访问层项目）。这使得 UI 类不可能意外地依赖于数据访问类。然而，这种方法的缺点是它并不总是容易做到。例如，使用 ASP.NET Core MVC，将控制器和视图模型移动到一个单独的项目是微不足道的，但对视图和客户端资源执行相同的操作可能非常具有挑战性。

It’s not a requirement for the Composition Root to be placed in the same project as your UI layer. You can move the UI layer out of the application’s root project. The advantage of this is that you can prevent the project that holds the UI layer from taking on a dependency (for instance, the data access layer project in chapter 3). This makes it impossible for UI classes to accidentally depend on data access classes. The downside of this approach, however, is that it isn’t always easy to do. With ASP.NET Core MVC, for instance, it’s trivial to move controllers and view models to a separate project, but it can be quite challenging to do the same with your views and client resources.

将表示技术与组合根分开可能也不是那么有益，因为组合根是特定于应用程序的。Composition Roots不被重用。

Separating the presentation technology from the Composition Root might not be that beneficial, either, because a Composition Root is specific to the application. Composition Roots aren’t reused.

您不应尝试在任何其他模块中组合类，因为这种方法会限制您的选择。应用程序模块中的所有类都应该使用构造函数注入（或者，在极少数情况下，使用本章其他两种模式之一），然后将其留给组合根来组合应用程序的对象图。任何使用中的DI 容器都应限制在Composition Root中。

You shouldn’t attempt to compose classes in any of the other modules, because that approach limits your options. All classes in application modules should use Constructor Injection (or, in rare cases, one of the other two patterns from this chapter), and then leave it up to the Composition Root to compose the application’s object graph. Any DI Container in use should be limited to the Composition Root.

在应用程序中，复合根应该是唯一知道构造对象图结构的地方。应用程序代码不仅放弃了对其依赖项的控制，还放弃了有关其依赖项的知识。集中这些知识可以简化开发。这也意味着应用程序代码无法将依赖项传递给与当前操作并行运行的其他线程，因为消费者无法知道这样做是否安全。相反，当分离并发操作时，组合根的工作是为每个并发操作创建一个新的对象图。

In an application, the Composition Root should be the sole place that knows about the structure of the constructed object graphs. Application code not only relinquishes control over its Dependencies, it also relinquishes knowledge about its Dependencies. Centralizing this knowledge simplifies development. This also means that application code can’t pass on Dependencies to other threads that run parallel to the current operation, because a consumer has no way of knowing whether it’s safe to do so. Instead, when spinning off concurrent operations, it’s the job of the Composition Root to create a new object graph for each concurrent operation.

清单 4.2中的Composition Root显示了Pure DI的示例。然而，组合根模式同时适用于纯 DI和DI 容器。在下一节中，我们将描述如何在Composition Root中使用DI Container。

The Composition Root in listing 4.2 showed an example of Pure DI. The Composition Root pattern, however, is both applicable to Pure DI and DI Containers. In the next section, we’ll describe how a DI Container can be used in a Composition Root.

4.1.2在组合根中使用DI 容器

4.1.2 Using a DI Container in a Composition Root

如第 3 章所述，DI 容器是一个软件库，可以自动执行许多涉及组合对象和管理其生命周期的任务。但它可能被滥用为服务定位器并且应该只用作组成对象图的引擎。当您从这个角度考虑DI 容器时，将其约束到Composition Root是有意义的。这也大大有利于消除DI 容器与应用程序代码库的其余部分之间的任何耦合。

As described in chapter 3, a DI Container is a software library that can automate many of the tasks involved in composing objects and managing their lifetimes. But it can be misused as a Service Locator and should only be used as an engine that composes object graphs. When you consider a DI Container from that perspective, it makes sense to constrain it to the Composition Root. This also significantly benefits the removal of any coupling between the DI Container and the rest of the application’s code base.

Composition Root可以用DI Container来实现。这意味着您使用容器在对其Resolve方法的一次调用中组成整个应用程序的对象图. 当我们与开发人员谈论这样做时，我们总是可以说这让他们感到不舒服，因为他们担心这样做效率低下并且对性能不利。你不必为此担心。几乎从来没有出现过这种情况，在出现这种情况的少数情况下，有一些方法可以解决这个问题，正如我们将在 8.4.2 节中讨论的那样。

A Composition Root can be implemented with a DI Container. This means that you use the container to compose the entire application’s object graph in a single call to its Resolve method. When we talk to developers about doing it like this, we can always tell that it makes them uncomfortable because they’re afraid that it’s terribly inefficient and bad for performance. You don’t have to worry about that. That’s almost never the case and, in the few situations where it is, there are ways to address the issue, as we’ll discuss in section 8.4.2.

不用担心使用DI 容器组合大型对象图的性能开销。这通常不是问题。在第 4 部分中，我们将深入探讨DI 容器并展示如何在Composition Root中使用DI 容器。

Don’t worry about the performance overhead of using a DI Container to compose large object graphs. It’s usually not an issue. In part 4, we’ll do a deep dive into DI Containers and show how to use a DI Container inside the Composition Root.

对于基于请求的应用程序，例如网站和服务，您只需配置一次容器，然后为每个传入请求解析一个对象图。第 3 章中的电子商务 Web 应用程序就是一个例子。

When it comes to request-based applications, such as websites and services, you configure the container once, but resolve an object graph for each incoming request. The e-commerce web application in chapter 3 is an example of that.

4.1.3 示例：使用纯 DI实现合成根

4.1.3 Example: Implementing a Composition Root using Pure DI

示例电子商务 Web 应用程序必须有一个组合根来为传入的 HTTP 请求组合对象图。与所有其他 ASP.NET Core Web 应用程序一样，入口点在Main方法中. 然而，默认情况下，MainASP.NET Core 应用程序的方法将大部分工作委托给Startup类. 这个Startup类对我们来说足够接近应用程序的入口点，我们将使用它作为我们的Composition Root。

The sample e-commerce web application must have a Composition Root to compose object graphs for incoming HTTP requests. As with all other ASP.NET Core web applications, the entry point is in the Main method. By default, however, the Main method of an ASP.NET Core application delegates most of the work to the Startup class. This Startup class is close enough to the application’s entry point for us, and we’ll use that as our Composition Root.

与前面的控制台应用程序示例一样，我们使用Pure DI. 这意味着您使用普通的旧 C# 代码而不是DI 容器来编写对象图，如以下清单所示。

As in the previous example with the console application, we use Pure DI. This means you compose your object graphs using plain old C# code instead of a DI Container, as shown in the following listing.

清单 4.3 电子商务应用程序的Startup类

Listing 4.3 The e-commerce application’s Startup class

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        this.Configuration = configuration;    ①  
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(    ②  
        IServiceCollection services)
    {
        services.AddMvc();

        services.AddHttpContextAccessor();    ③  

        var connectionString =    ④  
            this.Configuration.GetConnectionString(    ④  
                "CommerceConnection");    ④  

        services.AddSingleton<IControllerActivator>(    ⑤  
            new CommerceControllerActivator(    ⑤  
                connectionString));    ⑤  
    }

    ...
}

如果你不熟悉 ASP.NET Core，这里有一个简单的解释：Startup类是必需的；这是您应用所需管道的地方。有趣的部分是. 应用程序的整个设置都封装在类中CommerceControllerActivatorCommerceControllerActivator，我们很快就会展示。

If you’re not familiar with ASP.NET Core, here’s a simple explanation: the Startup class is a necessity; it’s where you apply the required plumbing. The interesting part is the CommerceControllerActivator. The entire setup for the application is encapsulated in the CommerceControllerActivator class, which we’ll show shortly.

要启用将 MVC 控制器连接到应用程序，您必须在 ASP.NET Core MVC 中使用适当的Seam ，称为 an （在 7.3 节中详细讨论）。现在，了解要与 ASP.NET Core MVC 集成就足够了，您必须为组合根创建一个适配器并将其告知框架。IControllerActivator

To enable wiring MVC controllers to the application, you must employ the appropriate Seam in ASP.NET Core MVC, called an IControllerActivator (discussed in detail in section 7.3). For now, it’s enough to understand that to integrate with ASP.NET Core MVC, you must create an Adapter for your Composition Root and tell the framework about it.

Startup.ConfigureServices方法_只运行一次。因此，您的类是仅初始化一次的单个实例。因为您使用自定义设置 ASP.NET Core MVC，所以MVC 调用它的方法CommerceControllerActivatorIControllerActivatorCreate为每个传入的 HTTP 请求创建一个新的控制器实例（您可以在第 7.3 节中阅读详细信息）。以下清单显示了CommerceControllerActivator.

The Startup.ConfigureServices method only runs once. As a result, your CommerceControllerActivator class is a single instance that’s only initialized once. Because you set up ASP.NET Core MVC with the custom IControllerActivator, MVC invokes its Create method to create a new controller instance for each incoming HTTP request (you can read about the details in section 7.3). The following listing shows the CommerceControllerActivator.

清单 4.4 应用程序的实现IControllerActivator

Listing 4.4 The application’s IControllerActivator implementation

public class CommerceControllerActivator : IControllerActivator
{
    private readonly string connectionString;

    public CommerceControllerActivator(string connectionString)
    {
        this.connectionString = connectionString;
    }

    public object Create(ControllerContext ctx)    ①  
    {
        Type type = ctx.ActionDescriptor
            .ControllerTypeInfo.AsType();

        if (type == typeof(HomeController))    ②  
        {
            return
                new HomeController(
                    new ProductService(
                        new SqlProductRepository(
                            new CommerceContext(
                                this.connectionString)),
                        new AspNetUserContextAdapter()));
        }
        else
        {
            throw new Exception("Unknown controller.");  ③  
        }
    }
}

注意这个例子中 的创建与我们在清单 4.1HomeController中展示的第 3 章中的应用程序对象图几乎完全相同。当 MVC 调用时，您确定控制器类型并基于此类型创建正确的对象图。Create

Notice how the creation of HomeController in this example is almost identical to the application’s object graph from chapter 3 that we showed in listing 4.1. When MVC calls Create, you determine the controller type and create the correct object graph based on this type.

在 2.3.3 节中，我们讨论了如何只有组合根应该依赖配置文件，因为对于可重用库来说，调用者可以强制配置它更加灵活。您还应该将配置值的加载与执行对象组合的方法分开（如清单 4.3 和 4.4 所示）。清单 4.3的Startup类加载配置，而清单4.4的类仅依赖于配置值，而不依赖于配置系统。这种分离的一个重要优点是它将对象组合与使用中的配置系统分离，从而可以在不存在（有效的）配置文件的情况下进行测试。CommerceControllerActivator

In section 2.3.3, we discussed how only the Composition Root should rely on configuration files, because it’s more flexible for reusable libraries to be imperatively configurable by their callers. You should also separate the loading of configuration values from the methods that do Object Composition (as shown in listings 4.3 and 4.4). The Startup class of listing 4.3 loads the configuration, whereas the CommerceControllerActivator of listing 4.4 only depends on the configuration value, not the configuration system. An important advantage of this separation is that it decouples Object Composition from the configuration system in use, making it possible to test without the existence of a (valid) configuration file.

本例中的Composition Root分布在两个类中，如图 4.2所示。这是意料之中的。重要的是所有类都包含在同一个模块中，在本例中，该模块是应用程序根。

The Composition Root in this example is spread out across two classes, as shown in figure 4.2. This is expected. The important thing is that all classes are contained in the same module, which, in this case, is the application root.

在此图中要注意的最重要的事情是，这两个类是整个示例应用程序中仅有的组成对象图的类。其余应用程序代码仅使用构造函数注入模式.

The most important thing to notice in this figure is that these two classes are the only classes in the entire sample application that compose object graphs. The remaining application code only uses the Constructor Injection pattern.

4.1.4 明显的依赖性爆炸

4.1.4 The apparent dependency explosion

开发人员经常听到的抱怨是，组合根导致应用程序的入口点依赖于应用程序中的所有其他程序集。在他们旧的、紧密耦合的代码库中，他们的入口点只需要依赖于直接在下面的层。这似乎是落后的，因为 DI 旨在减少所需的依赖项数量。他们认为使用 DI 会导致其应用程序入口点的依赖性激增——至少看起来是这样。

An often-heard complaint from developers is that the Composition Root causes the application’s entry point to take a dependency on all other assemblies in the application. In their old, tightly coupled code bases, their entry point only needed to depend on the layer directly below. This seems backward because DI is meant to lower the required number of dependencies. They see the use of DI as causing an explosion of dependencies in their application’s entry point — or so it seems.

这种抱怨源于开发人员误解了项目依赖项的工作方式。为了更好地了解他们担心的是什么，让我们看一下第 2 章中 Mary 应用程序的依赖图，并将其与第 3 章松散耦合应用程序的依赖图（图 4.3）进行比较。

This complaint comes from the fact that developers misunderstand how project dependencies work. To get a good view of what they’re worried about, let’s take a look at the dependency graph of Mary’s application from chapter 2 and compare that with the dependency graph of the loosely coupled application of chapter 3 (figure 4.3).

乍一看，与 Mary 的应用程序“只有”三个依赖项相比，松散耦合的应用程序中似乎确实多了两个依赖项。然而，该图具有误导性。

At first glance, it indeed looks as if there are two more dependencies in the loosely coupled application, compared to Mary’s application with “only” three dependencies. The diagram, however, is misleading.

对数据访问层的更改也会波及到 UI 层，正如我们在上一章中讨论的那样，没有数据访问层就无法部署 UI 层。尽管图中没有显示，但 UI 和数据访问层之间存在依赖关系。程序集依赖项实际上是可传递的。

Changes to the data access layer also ripple through the UI layer and, as we discussed in the previous chapter, the UI layer can’t be deployed without the data access layer. Even though the diagram doesn’t show it, there’s a dependency between the UI and the data access layer. Assembly dependencies are in fact transitive.

这种传递关系意味着，因为 Mary 的 UI 依赖于域，而域依赖于数据访问，所以 UI 也依赖于数据访问，这正是您在部署应用程序时会遇到的行为。如果您查看 Mary 的应用程序中项目之间的依赖关系，您会发现一些不同的东西（图 4.4）。

This transitive relationship means that because Mary’s UI depends on the domain, and the domain depends on data access, the UI depends on data access too, which is exactly the behavior you’ll experience when deploying the application. If you take a look at the dependencies between the projects in Mary’s application, you’ll see something different (figure 4.4).

如您所见，即使在 Mary 的应用程序中，入口点也取决于所有库。Mary 的入口点和松耦合应用程序的组合根具有相同数量的依赖项。但是请记住，依赖性不是由模块的数量定义的，而是由每个模块依赖另一个模块的次数定义的。结果，Mary 的应用程序中所有模块之间的依赖项总数实际上是六个。这比松散耦合的应用程序多了一个。

As you can see, even in Mary’s application, the entry point depends on all libraries. Both Mary’s entry point and the Composition Root of the loosely coupled application have the same number of dependencies. Remember, though, that dependencies aren’t defined by the number of modules, but the number of times each module depends on another module. As a result, the total number of dependencies between all modules in Mary’s application is, in fact, six. That’s one more than the loosely coupled application.

现在想象一个包含数十个项目的应用程序。不难想象，与松散耦合的代码库相比，紧密耦合的代码库中的依赖项数量是如何爆炸式增长的。但是，通过编写应用组合根模式的松散耦合代码，您可以减少依赖项的数量。正如您在上一章中看到的，这使您可以用不同的模块替换完整的模块，这在紧密耦合的代码库中更难。

Now imagine an application with dozens of projects. It’s not hard to imagine how the number of dependencies in a tightly coupled code base explodes compared with a loosely coupled code base. But, by writing loosely coupled code that applies the Composition Root pattern, you can lower the number of dependencies. As you’ve seen in the previous chapter, this lets you replace complete modules with different ones, which is harder in a tightly coupled code base.

Composition Root模式适用于所有使用 DI 开发的应用程序，但只有启动项目才会有Composition Root。组合根是消除消费者创建依赖关系的责任的结果。为此，您可以应用两种模式：构造函数注入和财产注入. 构造函数注入是最常见的，应该几乎完全使用。因为构造函数注入是最常用的模式，所以我们接下来会讨论它。

The Composition Root pattern applies to all applications developed using DI, but only startup projects will have a Composition Root. A Composition Root is the result of removing the responsibility for the creation of Dependencies from consumers. To achieve this, you can apply two patterns: Constructor Injection and Property Injection. Constructor Injection is the most common and should be used almost exclusively. Because Constructor Injection is the most commonly used pattern, we’ll discuss that next.

4.2 构造函数注入

4.2 Constructor Injection

当类需要Dependency的实例时，您可以通过类的构造函数提供该Dependency，使其能够存储引用以供将来使用。

When a class requires an instance of a Dependency, you can supply that Dependency through the class’s constructor, enabling it to store the reference for future use.

构造函数签名与类型一起编译，并且可供所有人查看。它清楚地记录了该类需要通过其构造函数请求的依赖项。图 4.5演示了这一点。

The constructor signature is compiled with the type and is available for all to see. It clearly documents that the class requires the Dependencies it requests through its constructor. Figure 4.5 demonstrates this.

此图显示消费类需要依赖HomeController项的实例才能工作，因此它需要组合根（客户端）通过其构造函数提供实例。这保证了实例在需要时可用。IProductService HomeController

This figure shows that the consuming class HomeController needs an instance of the IProductService Dependency to work, so it requires the Composition Root (the client) to supply an instance via its constructor. This guarantees that the instance is available to HomeController when it’s needed.

4.2.1构造函数注入如何工作

4.2.1 How Constructor Injection works

需要依赖项的类必须公开一个公共构造函数，该构造函数将所需依赖项的实例作为构造函数参数。这应该是唯一公开可用的构造函数。如果需要多个Dependency，可以将额外的构造函数参数添加到同一个构造函数中。清单 4.5显示了HomeController类的定义图4.5。

The class that needs the Dependency must expose a public constructor that takes an instance of the required Dependency as a constructor argument. This should be the only publicly available constructor. If more than one Dependency is needed, additional constructor arguments can be added to the same constructor. Listing 4.5 shows the definition of the HomeController class of figure 4.5.

清单 4.5使用构造函数注入 注入依赖

Listing 4.5 Injecting a Dependency using Constructor Injection

public class HomeController
{
    private readonly IProductService service;    ①  

    public HomeController(    ②  
        IProductService service)    ③  
    {
        if (service == null)    ④  
            throw new ArgumentNullException("service");  ④  

        this.service = service;    ⑤  
    }
}

IProductService Dependency是一个必需的构造函数参数HomeController；任何不提供实例的客户端IProductService都无法编译。但是，因为接口是引用类型，调用者可以作为参数传入以使调用代码编译。您需要使用保护条款来保护班级免受此类滥用。¹  因为编译器和 Guard Clause 的共同努力保证了构造函数参数在没有抛出异常的情况下有效，构造函数可以存储依赖以供将来使用，而无需了解真正的实现。null

The IProductService Dependency is a required constructor argument of HomeController; any client that doesn’t supply an instance of IProductService can’t compile. But, because an interface is a reference type, a caller can pass in null as an argument to make the calling code compile. You need to protect the class against such misuse with a Guard Clause.¹  Because the combined efforts of the compiler and the Guard Clause guarantee that the constructor argument is valid if no exception is thrown, the constructor can store the Dependency for future use without knowing anything about the real implementation.

将保存依赖项的字段标记为readonly. 这保证一旦构造函数的初始化逻辑执行完毕，该字段就不能被修改。null从 DI 的角度来看，这并不是严格要求的，但它可以防止您在依赖类代码的其他地方意外修改该字段（例如将其设置为）。

It’s good practice to mark the field holding the Dependency as readonly. This guarantees that once the initialization logic of the constructor has executed, the field can’t be modified. This isn’t strictly required from a DI point of view, but it protects you from accidentally modifying the field (such as setting it to null) somewhere else in the depending class’s code.

当构造函数返回时，类的新实例与注入其中的依赖项的正确实例处于一致状态。因为构造的类持有对此Dependency的引用，所以它可以经常使用Dependency任何其他成员所必需的。它的成员不需要测试null，因为实例保证存在。

When the constructor has returned, the new instance of the class is in a consistent state with a proper instance of its Dependency injected into it. Because the constructed class holds a reference to this Dependency, it can use the Dependency as often as necessary from any of its other members. Its members don’t need to test for null, because the instance is guaranteed to be present.

4.2.2 何时使用构造函数注入

4.2.2 When to use Constructor Injection

构造函数注入应该是 DI 的默认选择。它解决了一个类需要一个或多个Dependencies并且没有合理的Local Defaults可用的最常见场景。

Constructor Injection should be your default choice for DI. It addresses the most common scenario where a class requires one or more Dependencies, and no reasonable Local Defaults are available.

构造函数注入解决了对象需要依赖但没有合理的本地默认可用的常见情况，因为它保证必须提供依赖。如果依赖类在没有Dependency的情况下绝对无法运行，那么这种保证就很有价值。表 4.1总结了构造函数注入的优点和缺点。

Constructor Injection addresses the common scenario of an object requiring a Dependency with no reasonable Local Default available, because it guarantees that the Dependency must be provided. If the depending class absolutely can’t function without the Dependency, such a guarantee is valuable. Table 4.1 provides a summary of the advantages and disadvantages of Constructor Injection.

在本地库可以提供良好默认实现的情况下，属性注入也可能是一个很好的选择，但通常情况并非如此。在前面的章节中，我们展示了许多将存储库作为依赖项的示例。这些是Dependencies的好例子，其中本地库不能提供好的默认实现，因为正确的实现属于专门的数据访问库。除了已经讨论过的保证注入之外，使用清单 4.5中的结构也很容易实现这种模式。

In cases where the local library can supply a good default implementation, Property Injection can also be a good fit, but this is usually not the case. In the earlier chapters, we showed many examples of Repositories as Dependencies. These are good examples of Dependencies, where the local library can supply no good default implementation because the proper implementations belong in specialized data access libraries. Apart from the guaranteed injection already discussed, this pattern is also easy to implement using the structure presented in listing 4.5.

Constructor Injection的主要缺点是，如果您正在构建的类被您当前的应用程序框架调用，您可能需要自定义该框架以支持它。某些框架，尤其是较旧的框架，假定您的类将具有无参数构造函数。³   （这称为约束构造反模式，我们将在下一章中更详细地讨论这个问题。）在这种情况下，当无参数构造函数不可用时，框架将需要特殊帮助来创建实例。在第 7 章中，我们将解释如何为常见的应用程序框架启用构造函数注入。

The main disadvantage to Constructor Injection is that if the class you’re building is called by your current application framework, you might need to customize that framework to support it. Some frameworks, especially older ones, assume that your classes will have a parameterless constructor.³  (This is called the Constrained Construction anti-pattern, and we’ll discuss this in more detail in the next chapter.) In this case, the framework will need special help creating instances when a parameterless constructor isn’t available. In chapter 7, we’ll explain how to enable Constructor Injection for common application frameworks.

正如之前在 4.1 节中讨论的那样，构造函数注入的一个明显缺点是它需要立即初始化整个依赖图。虽然这听起来效率低下，但这很少成为问题。毕竟，即使对于复杂的对象图，我们通常也是在谈论创建几十个新的对象实例，而创建对象实例是 .NET Framework 执行速度非常快的事情。您的应用程序可能存在的任何性能瓶颈都会出现在其他地方，所以不用担心。^4个 

As previously discussed in section 4.1, an apparent disadvantage of Constructor Injection is that it requires that the entire Dependency graph be initialized immediately. Although this sounds inefficient, it’s rarely an issue. After all, even for a complex object graph, we’re typically talking about creating a few dozen new object instances, and creating an object instance is something the .NET Framework does extremely fast. Any performance bottleneck your application may have will appear in other places, so don’t worry about it.⁴ 

现在您知道构造函数注入是应用 DI 的首选方式，让我们看一些已知的示例。为此，我们接下来将讨论.NET BCL 中的构造函数注入。

Now that you know that Constructor Injection is the preferred way of applying DI, let’s take a look at some known examples. For this, we’ll discuss Constructor Injection in the .NET BCL next.

4.2.3构造函数注入的已知用法

4.2.3 Known use of Constructor Injection

尽管构造函数注入在使用 DI 的应用程序中普遍存在，但它在 BCL 中并不常见。这主要是因为 BCL 是一组可重用的库，而不是一个成熟的应用程序。您可以在 BCL 中看到某种构造函数注入的两个相关示例是和类System.IO.StreamReaderSystem.IO.StreamWriter. 两者都System.IO.Stream在其构造函数中获取一个实例。这是所有与StreamWritersStream相关的构造函数；StreamReader构造函数是相似的：

Although Constructor Injection tends to be ubiquitous in applications employing DI, it isn’t very present in the BCL. This is mainly because the BCL is a set of reusable libraries and not a full-fledged application. Two related examples where you can see a sort of Constructor Injection in the BCL is with the System.IO.StreamReader and System.IO.StreamWriter classes. Both take a System.IO.Stream instance in their constructors. Here’s all of StreamWriter's Stream-related constructors; the StreamReader constructors are similar:

public StreamWriter(Stream stream);
public StreamWriter(Stream stream, Encoding encoding);
public StreamWriter(Stream stream, Encoding encoding, int bufferSize);

Stream是一个抽象类，作为抽象类，并在其上StreamWriter运行StreamReader以履行其职责。你可以提供任何Stream 在他们的构造函数中实现，他们会使用它，但ArgumentNullExceptions如果你试图给他们一个null流，他们会抛出。

Stream is an abstract class that serves as an Abstraction on which StreamWriter and StreamReader operate to perform their duties. You can supply any Stream implementation in their constructors, and they’ll use it, but they’ll throw ArgumentNullExceptions if you try to slip them a null stream.

尽管 BCL 提供了示例，您可以在其中看到正在使用的构造函数注入，但查看工作示例总是更有指导意义。下一节将带您完成一个完整的实施示例。

Although the BCL provides examples where you can see Constructor Injection in use, it’s always more instructive to see a working example. The next section walks you through a full implementation example.

4.2.4 示例：向特色产品添加货币换算

4.2.4 Example: Adding currency conversions to the featured products

玛丽的老板说她的应用程序运行良好，但现在一些使用它的客户想要使用不同的货币支付商品。她能否编写一些新代码，使该应用程序能够以不同货币显示和计算成本？Mary 叹了口气，意识到硬编码几种不同的货币换算是不够的。随着时间的推移，她需要编写足够灵活的代码来适应任何货币。DI 又来电了。

Mary’s boss says her app is working fine, but now some customers who are using it want to pay for goods in different currencies. Can she write some new code that enables the app to display and calculate costs in different currencies? Mary sighs and realizes that it’s not going to be enough to hard-code in a few different currency conversions. She’ll need to write code flexible enough to accommodate any currency over time. DI is calling again.

Mary 需要的既是表示货币及其货币的对象，又是允许将货币从一种货币转换为另一种货币的抽象。她会给抽象 命名。为简单起见， the将只有一个 currency ，并且由 a和 an组成，如图 4.6所示。ICurrencyConverterCurrencyCodeMoneyCurrencyAmount

What Mary needs is both an object for representing money and its currency and an Abstraction that allows converting money from one currency into another. She’ll name the Abstraction ICurrencyConverter. For simplicity, the Currency will only have a currency Code, and Money is composed of both a Currency and an Amount, as shown in figure 4.6.

下面的清单显示了类和Currency接口，如图 4.6 所示。MoneyICurrencyConverter

The following listing shows the Currency and Money classes, and the ICurrencyConverter interface, as envisioned in figure 4.6.

清单4.6Currency和界面MoneyICurrencyConverter

Listing 4.6 Currency, Money, and the ICurrencyConverter interface

public interface ICurrencyConverter
{
    Money Exchange(Money money, Currency targetCurrency);
}

public class Currency
{
    public readonly string Code;

    public Currency(string code)
    {
        if (code == null) throw new ArgumentNullException("code");

        this.Code = code;
    }
}

public class Money
{
    public readonly decimal Amount;
    public readonly Currency Currency;

    public Money(decimal amount, Currency currency)
    {
        if (currency == null) throw new ArgumentNullException("currency");

        this.Amount = amount;
        this.Currency = currency;
    }
}

可能表示进程外资源，例如 Web 服务或提供转换率的数据库。这意味着在单独的项目（例如数据访问层）中实现具体的内容是合适的。因此，没有合理的本地默认值ICurrencyConverterICurrencyConverter.

An ICurrencyConverter is likely to represent an out-of-process resource, such as a web service or a database that supplies conversion rates. This means that it’d be fitting to implement a concrete ICurrencyConverter in a separate project, such as a data access layer. Hence, there’s no reasonable Local Default.

同时，ProductService班级将需要一个ICurrencyConverter. 构造函数注入非常适合。以下清单显示了如何将ICurrencyConverter 依赖项注入到ProductService.

At the same time, the ProductService class will need an ICurrencyConverter. Constructor Injection is a good fit. The following listing shows how the ICurrencyConverter Dependency is injected into ProductService.

清单 4.7 注入ICurrencyConverter一个ProductService

Listing 4.7 Injecting an ICurrencyConverter into ProductService

public class ProductService : IProductService
{
    private readonly IProductRepository repository;
    private readonly IUserContext userContext;
    private readonly ICurrencyConverter converter;

    public ProductService(
        IProductRepository repository,
        IUserContext userContext,
        ICurrencyConverter converter)
    {
        if (repository == null)
            throw new ArgumentNullException("repository");
        if (userContext == null)
            throw new ArgumentNullException("userContext");
        if (converter == null)
            throw new ArgumentNullException("converter");

        this.repository = repository;
        this.userContext = userContext;
        this.converter = converter;
    }
}

因为ProductService班已经有了对 and 的依赖，我们添加新的依赖作为第三个构造函数参数，然后按照清单 4.5中列出的相同顺序进行操作。警卫IProductRepositoryIUserContextICurrencyConverter Clauses 保证Dependencies不为 null，这意味着将它们存储起来以供以后在只读字段中使用是安全的。因为 anICurrencyConverter保证存在于 中ProductService，所以它可以在任何地方使用；例如，在GetFeaturedProducts方法中如此处所示。

Because the ProductService class already had a Dependency on IProductRepository and IUserContext, we add the new ICurrencyConverter Dependency as a third constructor argument and then follow the same sequence outlined in listing 4.5. Guard Clauses guarantee that the Dependencies aren’t null, which means it’s safe to store them for later use in read-only fields. Because an ICurrencyConverter is guaranteed to be present in ProductService, it can be used from anywhere; for example, in the GetFeaturedProducts method as shown here.

清单 4.8 ProductService使用ICurrencyConverter

Listing 4.8 ProductService using ICurrencyConverter

public IEnumerable<DiscountedProduct> GetFeaturedProducts()
{
    Currency userCurrency = this.userContext.Currency;    ①  

    var products =
        this.repository.GetFeaturedProducts();

    return
        from product in products
        let unitPrice = product.UnitPrice    ②  
        let amount = this.converter.Exchange(    ③  
            money: unitPrice,    ③  
            targetCurrency: userCurrency)    ③  
        select product
            .WithUnitPrice(amount)
            .ApplyDiscountFor(this.userContext);
}

请注意，您可以使用该converter字段无需提前检查其可用性。那是因为它保证存在。

Notice that you can use the converter field without needing to check its availability in advance. That’s because it’s guaranteed to be present.

4.2.5 总结

4.2.5 Wrap-up

构造函数注入是可用的最普遍适用的 DI 模式，也是最容易正确实现的模式。它适用于需要依赖项时。如果您需要使依赖项成为可选的，您可以更改为Property Injection如果它有一个合适的Local Default。

Constructor Injection is the most generally applicable DI pattern available, and also the easiest to implement correctly. It applies when the Dependency is required. If you need to make the Dependency optional, you can change to Property Injection if it has a proper Local Default.

本章的下一个模式是方法注入，它采用的方法略有不同。它往往更适用于您已经拥有要传递给调用的协作者的依赖项的情况。

The next pattern in this chapter is Method Injection, which takes a slightly different approach. It tends to apply more to the situation where you already have a Dependency that you want to pass on to the collaborators you invoke.

4.3 方法注入

4.3 Method Injection

在Dependency可以随每个方法调用而变化的情况下，或者这种Dependency的消费者可以在每次调用时变化的情况下，您可以通过方法参数提供Dependency 。

In cases where a Dependency can vary with each method call, or the consumer of such a Dependency can vary on each call, you can supply a Dependency via a method parameter.

4.3.1方法注入如何工作

4.3.1 How Method Injection works

调用者在每个方法调用中提供依赖项作为方法参数。Mary 的电子商务应用程序中的这种方法的一个示例是在Product类中，其中ApplyDiscountFor方法使用方法注入接受IUserContext 依赖项：

The caller supplies the Dependency as a method parameter in each method call. An example of this approach in Mary’s e-commerce application is in the Product class, where the ApplyDiscountFor method accepts an IUserContext Dependency using Method Injection:

IUserContext提供要运行的操作的上下文信息，这是方法注入的常见场景。通常这个上下文将与一个“适当的”值一起提供给一个方法，如清单 4.9所示。

IUserContext presents contextual information for the operation to run, which is a common scenario for Method Injection. Often this context will be supplied to a method alongside a “proper” value, as shown in listing 4.9.

清单 4.9将依赖项与适当的值一起 传递

Listing 4.9 Passing a Dependency alongside a proper value

public decimal CalculateDiscountPrice(decimal price, IUserContext context)
{
    if (context == null) throw new ArgumentNullException("context");

    decimal discount = context.IsInRole(Role.PreferredCustomer) ? .95m : 1;

    return price * discount;
}

值price参数表示该方法应该操作的值，而context包含有关操作的当前上下文的信息；在这种情况下，有关当前用户的信息。调用者向方法提供依赖项。正如您之前多次看到的那样，Guard Clause 保证上下文对方法体的其余部分可用。

The price value parameter represents the value on which the method is supposed to operate, whereas context contains information about the current context of the operation; in this case, information about the current user. The caller supplies the Dependency to the method. As you’ve seen many times before, the Guard Clause guarantees that the context is available to the rest of the method body.

4.3.2 何时使用方法注入

4.3.2 When to use Method Injection

方法注入不同于其他类型的 DI 模式，因为注入不是在组合根中发生，而是在调用时动态发生。这允许调用者提供特定于操作的上下文，这是 .NET BCL 中使用的常见扩展机制。表 4.2总结了方法注入的优点和缺点。

Method Injection is different from other types of DI patterns in that the injection doesn’t happen in a Composition Root but, rather, dynamically at invocation. This allows the caller to provide an operation-specific context, which is a common extensibility mechanism used in the .NET BCL. Table 4.2 provides a summary of the advantages and disadvantages of Method Injection.

应用方法注入有两个典型的用例：

There are two typical use cases for applying Method Injection:

• 当注入的依赖项的消费者在每次调用时发生变化
• When the consumer of the injected Dependency varies on each call
• 当注入的依赖项在每次调用消费者时发生变化
• When the injected Dependency varies on each call to a consumer

以下部分显示了每个示例。清单 4.9是消费者如何变化的一个例子。这是最常见的形式，因此我们将从提供另一个示例开始。

The following sections show an example of each. Listing 4.9 is an example of how the consumer varies. This is the most common form, which is why we’ll start with providing another example.

示例：在每次方法调用时改变Dependency的使用者

Example: Varying the Dependency's consumer on each method call

当你练习领域驱动设计时(DDD)，通常创建包含域逻辑的域实体，有效地将运行时数据与同一类中的行为混合。⁸  然而，实体通常不是在组合根中创建的。以下面的Customer Entity为例。

When you practice Domain-Driven Design (DDD), it’s common to create domain Entities that contain domain logic, effectively mixing runtime data with behavior in the same class.⁸  Entities, however, are typically not created within the Composition Root. Take the following Customer Entity, for example.

清单 4.10包含域逻辑但没有依赖项 的实体（尚未）

Listing 4.10 An Entity containing domain logic but no Dependencies (yet)

public class Customer    ①  
{
    public Guid Id { get; private set; }    ②  
    public string Name { get; private set; }    ②  

    public Customer(Guid id, string name)    ③  
    {
        ...
    }

    public void RedeemVoucher(Voucher voucher) ...    ④  


    public void MakePreferred() ...    ⑤  
}

清单 4.10中的和方法是域方法。实现让客户兑换优惠券的领域逻辑。（您购买本书时可能已经兑换了优惠券以获得折扣。）是该方法使用的值对象⁹   。，另一方面，实现促进客户的领域逻辑。普通客户可以升级为首选客户，这可能会提供某些优势和折扣，类似于常旅客航空公司的客户。RedeemVoucherMakePreferredRedeemVouchervoucherMakePreferred

The RedeemVoucher and MakePreferred methods in listing 4.10 are domain methods. RedeemVoucher implements the domain logic that lets the customer redeem a voucher. (You may have redeemed a voucher to get a discount when you purchased this book.) voucher is a value object⁹  used by the method. MakePreferred, on the other hand, implements the domain logic that promotes the customer. A regular customer could get upgraded to become a preferred customer, which might give certain advantages and discounts, similar to being a frequent flyer airline customer.

除了通常的数据成员集之外还包含行为的实体将很容易获得范围广泛的方法，每个方法都需要自己的Dependencies。尽管您可能想使用构造函数注入来注入此类Dependencies，但这会导致需要创建每个此类Entity及其所有Dependencies的情况，即使对于给定的用例可能只需要几个。这使测试Entity的逻辑变得复杂，因为所有Dependencies都需要提供给构造函数，即使测试可能只对少数Dependencies感兴趣。方法注入，如下一个清单所示，提供了一个更好的选择。

Entities that contain behavior besides their usual set of data members would easily get a wide range of methods, each requiring their own Dependencies. Although you might be tempted to use Constructor Injection to inject such Dependencies, that leads to a situation where each such Entity needs to be created with all of its Dependencies, even though only a few may be necessary for a given use case. This complicates testing the logic of an Entity, because all Dependencies need to be supplied to the constructor, even though a test might only be interested in a few Dependencies. Method Injection, as shown in the next listing, offers a better alternative.

清单 4.11使用方法注入 的实体

Listing 4.11 An Entity using Method Injection

public class Customer
{
    public Guid Id { get; private set; }
    public string Name { get; private set; }

    public Customer(Guid id, string name)
    {
        ...
    }

    public void RedeemVoucher(    ①  
        Voucher voucher,
        IVoucherRedemptionService service)
    {
        if (voucher == null)
            throw new ArgumentNullException("voucher");
        if (service == null)
            throw new ArgumentNullException("service");

        service.ApplyRedemptionForCustomer(
            voucher,
            this.Id);
    }

    public void MakePreferred(IEventHandler handler)    ①  
    {
        if (handler == null)
            throw new ArgumentNullException("handler");

        handler.Publish(new CustomerMadePreferred(this.Id));
    }
}

在CustomerServices组件内部，Customer的RedeemVoucher方法可以在通过调用传递依赖项时调用，如下所示。IVoucherRedemptionService

Inside a CustomerServices component, the Customer's RedeemVoucher method can be called while passing the IVoucherRedemptionService Dependency with the call, as shown next.

清单 4.12 使用方法注入传递依赖项的组件

Listing 4.12 A component using Method Injection to pass a Dependency

public class CustomerServices : ICustomerServices
{
    private readonly ICustomerRepository repository;
    private readonly IVoucherRedemptionService service;

    public CustomerServices(    ①  
        ICustomerRepository repository,    ①  
        IVoucherRedemptionService service)    ①  
    {
        this.repository = repository;
        this.service = service;
    }

    public void RedeemVoucher(
        Guid customerId, Voucher voucher)
    {
        var customer =
            this.repository.GetById(customerId);

        customer.RedeemVoucher(voucher, this.service);    ②  

        this.repository.Save(customer);
    }
}

在清单 4.12中，只请求了一个Customer实例。但是可以使用大量客户和优惠券一遍又一遍地调用单个实例，从而导致将相同的内容提供给许多不同的实例。是Dependency的消费者，当您重用Dependency时，您正在改变消费者。ICustomerRepositoryCustomerServicesIVoucherRedemptionServiceCustomerCustomerIVoucherRedemptionService

In listing 4.12, only a single Customer instance is requested from ICustomerRepository. But a single CustomerServices instance can be called over and over again using a multitude of customers and vouchers, causing the same IVoucherRedemptionService to be supplied to many different Customer instances. Customer is the consumer of the IVoucherRedemptionService Dependency and, while you’re reusing the Dependency, you’re varying the consumer.

这类似于清单 4.9中显示的第一个方法注入示例和方法ApplyDiscountFor在清单 3.8 中讨论。相反的情况是，当您改变依赖关系同时保持其消费者在附近时。

This is similar to the first Method Injection example shown in listing 4.9 and the ApplyDiscountFor method discussed in listing 3.8. The opposite case is when you vary the Dependency while keeping its consumers around.

示例：在每个方法调用上改变注入的依赖项

Example: Varying the injected Dependency on each method call

想象一个用于图形绘图应用程序的插件系统，您希望每个人都能够在其中插入自己的图像效果。外部图像效果可能需要有关运行时上下文的信息，这些信息可以由应用程序传递给图像效果。这是应用方法注入的典型用例。您可以定义以下接口来应用这些效果：

Imagine an add-in system for a graphical drawing application, where you want everyone to be able to plug in their own image effects. External image effects might require information about the runtime context, which can be passed on by the application to the image effect. This is a typical use case for applying Method Injection. You can define the following interface for applying those effects:

public interface IImageEffectAddIn    ①  
{
    Bitmap Apply(    ②  
        Bitmap source,
        IApplicationContext context);    ③  
}

的IImageEffectAddIn依赖项可以随每次调用方法而变化IApplicationContext Apply，为效果提供有关调用操作的上下文的信息。任何实现此接口的类都可以用作插件。一些实现可能根本不关心context，而其他实现会。

The IImageEffectAddIn's IApplicationContext Dependency can vary with each call to the Apply method, providing the effect with information about the context in which the operation is being invoked. Any class implementing this interface can be used as an add-in. Some implementations may not care about the context at all, whereas other implementations will.

客户端可以通过使用源和上下文调用每个加载项来使用加载项列表以返回聚合结果，如下一个清单所示。Bitmap

A client can use a list of add-ins by calling each with a source Bitmap and a context to return an aggregated result, as shown in the next listing.

清单 4.13 示例插件客户端

Listing 4.13 A sample add-in client

public Bitmap ApplyEffects(Bitmap source)
{
    if (source == null) throw new ArgumentNullException("source");

    Bitmap result = source;

    foreach (IImageEffectAddIn effect in this.effects)
    {
        result = effect.Apply(result, this.context);
    }

    return result;
}

私有effects字段是一个实例列表，它允许客户端循环遍历列表以调用每个加载项的方法IImageEffectAddInApply. 每次Apply在加载项上调用该方法时，由context字段表示的操作上下文作为方法参数传递：

The private effects field is a list of IImageEffectAddIn instances, which allows the client to loop through the list to invoke each add-in’s Apply method. Each time the Apply method is invoked on an add-in, the operation’s context, represented by the context field, is passed as a method parameter:

result = effect.Apply(result, this.context);

有时，价值和操作上下文被封装在一个抽象中，作为两者的组合。需要注意的重要一点是：正如您在两个示例中所见，通过方法注入注入的依赖成为抽象定义的一部分。如果Dependency包含由其直接调用者提供的运行时信息，这通常是可取的。

At times, the value and the operational context are encapsulated in a single Abstraction that works as a combination of both. An important thing to note is this: as you’ve seen in both examples, the Dependency injected via Method Injection becomes part of the definition of the Abstraction. This is typically desirable in case that Dependency contains runtime information that’s supplied by its direct callers.

在依赖是调用者的实现细节的情况下，您应该尝试防止抽象被“污染”；因此，构造函数注入是一个更好的选择。否则，您很容易最终将依赖项从应用程序对象图的顶部一直向下传递，从而导致彻底的更改。

In cases where the Dependency is an implementation detail to the caller, you should try to prevent the Abstraction from being “polluted”; therefore, Constructor Injection is a better pick. Otherwise, you could easily end up passing the Dependency from the top of our application’s object graph all the way down, causing sweeping changes.

前面的例子都展示了在Composition Root之外使用Method Injection。这是故意的。方法注入不适合在Composition Root中使用。在Composition Root中，方法注入可以使用其Dependencies初始化先前构造的类。然而，这样做会导致时间耦合，因此非常不鼓励这样做。

The previous examples all showed the use of Method Injection outside of the Composition Root. This is deliberate. Method Injection is unsuitable when used within the Composition Root. Within a Composition Root, Method Injection can initialize a previously constructed class with its Dependencies. Doing so, however, leads to Temporal Coupling and for that reason it’s highly discouraged.

时间耦合代码的味道

The Temporal Coupling code smell

时间耦合是 API 设计中的一个常见问题。当一个类的两个或多个成员之间存在隐式关系时，就会发生这种情况，要求客户先调用一个成员再调用另一个。这在时间维度上紧密耦合了成员。原型示例是使用Initialize方法，尽管可以找到大量其他示例——甚至在 BCL 中也是如此。例如，这种用法编译但在运行时失败：System.ServiceModel.EndpointAddressBuilder

Temporal Coupling is a common problem in API design. It occurs when there’s an implicit relationship between two or more members of a class, requiring clients to invoke one member before the other. This tightly couples the members in the temporal dimension. The archetypical example is the use of an Initialize method, although copious other examples can be found — even in the BCL. As an example, this usage of System.ServiceModel.EndpointAddressBuilder compiles but fails at runtime:

var builder = new EndpointAddressBuilder();
var address = builder.ToEndpointAddress();

事实证明，在创建 之前需要一个 URI。以下代码在运行时编译并成功：EndpointAddress

It turns out that an URI is required before an EndpointAddress can be created. The following code compiles and succeeds at runtime:

var builder = new EndpointAddressBuilder();
builder.Uri = new UriBuilder().Uri;
var address = builder.ToEndpointAddress();

API 没有暗示这是必要的，但属性之间存在时间耦合Uri和ToEndpointAddress方法.

The API provides no hint that this is necessary, but there’s a Temporal Coupling between the Uri property and the ToEndpointAddress method.

当在Composition Root内部应用时，重复出现的模式是使用某种Initialize方法，如代码清单 4.14所示。

When applied inside the Composition Root, a recurring pattern is the use of some Initialize method, as shown in listing 4.14.

清单 4.14 时间耦合示例

Listing 4.14 Temporal Coupling example

public class Component
{
    private ISomeInterface dependency;

    public void Initialize(    ①  
        ISomeInterface dependency)    ①  
    {
        this.dependency = dependency;
    }

    public void DoSomething()
    {
        if (this.dependency == null)    ②  
            throw new InvalidOperationException(    ②  
                "Call Initialize first.");    ②  

        this.dependency.DoStuff();
    }
}

在语义上，方法的名称是一个线索，但在结构层面上，这个 API 没有给我们任何Temporal CouplingInitialize的迹象。因此，像这样的代码可以编译，但会在运行时抛出异常：

Semantically, the name of the Initialize method is a clue, but on a structural level, this API gives us no indication of Temporal Coupling. Thus, code like this compiles, but throws an exception at runtime:

var c = new Component();
c.DoSomething();

这个问题的解决方案现在应该很明显了——你应该应用构造函数注入来代替：

The solution to this problem should be obvious by now — you should apply Constructor Injection instead:

public class Component
{
    private readonly ISomeInterface dependency;

    public Component(ISomeInterface dependency)
    {
        if (dependency == null)
            throw new ArgumentNullException("dependency");

        this.dependency = dependency;
    }

    public void DoSomething()
    {
        this.dependency.DoStuff();
    }
}

4.3.3 方法注入的已知用法

4.3.3 Known use of Method Injection

.NET BCL 提供了许多方法注入示例，尤其是在System.ComponentModel命名空间中。您用于为组件实现自定义设计时功能。它有一个方法System.ComponentModel.Design.IDesignerInitialize它需要一个IComponent实例，以便它知道它当前正在帮助设计哪个组件。（请注意，此Initialize方法会导致时间耦合。）设计器是由IDesignerHost实现创建的，这些实现也将IComponent实例作为参数来创建设计器：

The .NET BCL provides many examples of Method Injection, particularly in the System.ComponentModel namespace. You use System.ComponentModel.Design.IDesigner for implementing custom design-time functionality for components. It has an Initialize method that takes an IComponent instance so that it knows which component it’s currently helping to design. (Note that this Initialize method causes Temporal Coupling.) Designers are created by IDesignerHost implementations that also take IComponent instances as parameters to create designers:

IDesigner GetDesigner(IComponent component);

这是参数本身携带信息的场景的一个很好的例子。component可以携带有关创建哪些信息的信息IDesigner，但同时，它也是设计人员随后必须对其进行操作的组件。

This is a good example of a scenario where the parameter itself carries information. The component can carry information about which IDesigner to create, but at the same time, it’s also the component on which the designer must subsequently operate.

System.ComponentModel命名空间中的另一个例子由TypeConverter班级提供。顾名思义，它的几个方法采用了它的一个实例，传递有关当前操作上下文的信息，例如有关类型属性的信息。因为这样的方法很多，我们不想一一列举，这里举一个有代表性的例子：ITypeDescriptorContext

Another example in the System.ComponentModel namespace is provided by the TypeConverter class. Several of its methods take an instance of ITypeDescriptorContext that, as the name says, conveys information about the context of the current operation, such as information about the type’s properties. Because there are many such methods, we don’t want to list them all, but here’s a representative example:

public virtual object ConvertTo(ITypeDescriptorContext context,
    CultureInfo culture, object value, Type destinationType)

在此方法中，操作的上下文由context参数显式传达，而要转换的值和目标类型作为单独的参数发送。context实施者可以在他们认为合适的时候使用或忽略参数。

In this method, the context of the operation is communicated explicitly by the context parameter, whereas the value to be converted and the destination type are sent as separate parameters. Implementers can use or ignore the context parameter as they see fit.

ASP.NET Core MVC 还包含几个方法注入示例。你可以使用IValidationAttributeAdapterProvider界面，例如，提供实例。它唯一的方法是这样的：IAttributeAdapter

ASP.NET Core MVC also contains several examples of Method Injection. You can use the IValidationAttributeAdapterProvider interface, for instance, to provide IAttributeAdapter instances. Its only method is this:

IAttributeAdapter GetAttributeAdapter(
    ValidationAttribute attribute, IStringLocalizer stringLocalizer)

ASP.NET Core 允许将视图模型的属性标记为. 这是一种应用元数据的便捷方式，元数据描述封装在视图模型中的属性的有效性。ValidationAttribute

ASP.NET Core allows properties of view models to be marked with ValidationAttribute. It’s a convenient way to apply metadata that describes the validity of properties encapsulated in the view model.

该方法基于一个，允许返回一个 ，允许在网页中显示相关的错误信息。方法中，参数ValidationAttributeGetAttributeAdapterIAttributeAdapterGetAttributeAdapterattribute是IAttributeAdapter应该为其创建的对象，而stringLocalizer是通过方法注入传递的依赖项。

Based on a ValidationAttribute, the GetAttributeAdapter method allows an IAttributeAdapter to be returned, which allows relevant error messages to be displayed in a web page. In the GetAttributeAdapter method, the attribute parameter is the object an IAttributeAdapter should be created for, whereas the stringLocalizer is the Dependency that’s passed through Method Injection.

接下来，我们将看到 Mary 如何使用方法注入来防止代码重复。当我们最后一次见到 Mary（在 4.2 节）时，她正在做：她使用构造函数注入将它注入到类中。ICurrencyConverterProductService

Next, we’ll see how Mary uses Method Injection in order to prevent code repetition. When we last saw Mary (in section 4.2), she was working on ICurrencyConverter: she injected it using Constructor Injection into the ProductService class.

4.3.4 示例：向Product实体添加货币换算

4.3.4 Example: Adding currency conversions to the ProductEntity

清单 4.8展示了该GetFeaturedProducts方法是如何调用了ICurrencyConverter.Exchange方法在 Mary 的应用程序中使用产品UnitPrice和用户的首选货币。又是这个GetFeaturedProducts方法：

Listing 4.8 showed how the GetFeaturedProducts method called the ICurrencyConverter.Exchange method using the product’s UnitPrice and the user’s preferred currency in Mary’s application. Here’s that GetFeaturedProducts method again:

public IEnumerable<DiscountedProduct> GetFeaturedProducts()
{
    Currency currency = this.userContext.Currency;

    return
        from product in this.repository.GetFeaturedProducts()
        let amount = this.converter.Exchange(product.UnitPrice, currency)
        select product
            .WithUnitPrice(amount)
            .ApplyDiscountFor(this.userContext);
}

在她的应用程序的许多部分中，将Product 实体从一个实体转换为另一个实体将是一项重复出现的任务。Currency出于这个原因，Mary 喜欢将有关转换的逻辑Product移出ProductService并将其集中为Product Entity的一部分。这可以防止系统的其他部分重复此代码。事实证明，方法注入是一个很好的选择。Mary 在 中创建了一个新ConvertTo方法Product，如下一个清单所示。

Conversions of Product Entities from one Currency to another will be a recurring task in many parts of her application. For this reason, Mary likes to move the logic concerning the conversion of the Product out of ProductService and centralize it as part of the Product Entity. This prevents other parts of the system from repeating this code. Method Injection turns out to be a great candidate for this. Mary creates a new ConvertTo method in Product, as shown in the next listing.

清单 4.15 带有方法的Product实体ConvertTo

Listing 4.15 ProductEntity with ConvertTo method

public class Product
{
    public string Name { get; set; }
    public Money UnitPrice { get; set; }
    public bool IsFeatured { get; set; }

    public Product ConvertTo(
        Currency currency,    ①  
        ICurrencyConverter converter)    ②  
    {
        if (currency == null)
            throw new ArgumentNullException("currency");
        if (converter == null)
            throw new ArgumentNullException("converter");

        var newUnitPrice =
            converter.Exchange(    ③  
                this.UnitPrice,
                currency);

        return this.WithUnitPrice(newUnitPrice);    ④  
    }

    public Product WithUnitPrice(Money unitPrice)
    {
        return new Product
        {
            Name = this.Name,
            UnitPrice = unitPrice,
            IsFeatured = this.IsFeatured
        };
    }
    ...
}

使用新ConvertTo方法，Mary 重构了GetFeaturedProducts方法.

With the new ConvertTo method, Mary refactors the GetFeaturedProducts method.

清单 4.16 GetFeaturedProducts使用ConvertTo方法

Listing 4.16 GetFeaturedProducts using ConvertTo method

public IEnumerable<DiscountedProduct> GetFeaturedProducts()
{
    Currency currency = this.userContext.Currency;

    return
        from product in this.repository.GetFeaturedProducts()
        select product
            .ConvertTo(currency, this.converter)    ①  
            .ApplyDiscountFor(this.userContext);
}

而不是调用ICurrencyConverter.Exchange方法，如您之前所见，现在传递给使用方法注入的方法。当 Mary 需要在她的代码库中的其他地方转换产品时，这简化了方法并防止了任何代码重复。通过使用方法注入而不是构造函数注入，她避免了必须构建具有所有依赖项的实体。这简化了构造和测试。GetFeaturedProductsICurrencyConverterConvertToGetFeaturedProductsProduct

Instead of calling the ICurrencyConverter.Exchange method, as you’ve seen previously, GetFeaturedProducts now passes ICurrencyConverter on to the ConvertTo method using Method Injection. This simplifies the GetFeaturedProducts method and prevents any code duplication when Mary needs to convert products elsewhere in her code base. By using Method Injection instead of Constructor Injection, she avoided having to build up the Product Entity with all of its Dependencies. This simplifies construction and testing.

与本章中的其他 DI 模式不同，当您想要向已经存在的消费者提供依赖项时，您主要使用方法注入。另一方面，使用Constructor Injection和Property Injection ，您可以在消费者创建时向其提供依赖项。

Unlike the other DI patterns in this chapter, you mainly use Method Injection when you want to supply Dependencies to an already existing consumer. With Constructor Injection and Property Injection, on the other hand, you supply Dependencies to a consumer while it’s being created.

本章的最后一个模式是属性注入，它允许您覆盖类的本地默认值。方法注入仅在组合根外部应用，而属性注入，就像构造函数注入一样，是从组合根内部应用的。

The last pattern in this chapter is Property Injection, which allows you to override a class’s Local Default. Where Method Injection was solely applied outside the Composition Root, Property Injection, just as Constructor Injection, is applied from within the Composition Root.

4.4 属性注入

4.4 Property Injection

当一个类具有良好的Local Default，但您仍希望将其保持开放以实现可扩展性时，您可以公开一个可写属性，该属性允许客户端提供与默认类的依赖项不同的实现。如图4.8所示，想要按原样使用Consumer该类的客户可以创建该类的实例并使用它而无需再考虑，而想要修改该类行为的客户可以通过将Dependency属性设置为的不同实现IDependency。

When a class has a good Local Default, but you still want to leave it open for extensibility, you can expose a writable property that allows a client to supply a different implementation of the class’s Dependency than the default. As figure 4.8 shows, clients wanting to use the Consumer class as is can create an instance of the class and use it without giving it a second thought, whereas clients wanting to modify the behavior of the class can do so by setting the Dependency property to a different implementation of IDependency.

4.4.1属性注入如何工作

4.4.1 How Property Injection works

使用Dependency的类必须公开Dependency类型的公共可写属性。在基本实现中，这可以像下面的清单一样简单。

The class that uses the Dependency must expose a public writable property of the Dependency’s type. In a bare-bones implementation, this can be as simple as the following listing.

清单 4.17 属性注入

Listing 4.17 Property Injection

public class Consumer
{
    public IDependency Dependency { get; set; }
}

Consumer取决于IDependency. IDependency客户可以通过设置Dependency属性来提供实现.

Consumer depends on IDependency. Clients can supply implementations of IDependency by setting the Dependency property.

依赖类的其他成员可以使用注入的依赖来执行它们的职责，如下所示：

Other members of the depending class can use the injected Dependency to perform their duties, like this:

public void DoSomething()
{
    this.Dependency.DoStuff();
}

不幸的是，这样的实现是脆弱的。那是因为该Dependency属性不能保证返回 的实例IDependency。如果属性的值为：NullReferenceExceptionDependencynull

Unfortunately, such an implementation is fragile. That’s because the Dependency property isn’t guaranteed to return an instance of IDependency. Code like this would throw a NullReferenceException if the value of the Dependency property is null:

var instance = new Consumer();

instance.DoSomething();    ①  

这个问题可以通过让构造函数在属性上设置默认实例，并在属性的 setter 中结合适当的 Guard Clause 来解决。如果客户端在类的生命周期中间切换依赖关系，则会出现另一个复杂情况：

This issue can be solved by letting the constructor set a default instance on the property, combined with a proper Guard Clause in the property’s setter. Another complication arises if clients switch the Dependency in the middle of the class’s lifetime:

var instance = new Consumer();

instance.Dependency = new SomeImplementation();    ①  

instance.DoSomething();

instance.Dependency = new SomeOtherImplementation();    ②  

instance.DoSomething();

这可以通过引入一个只允许客户端在初始化期间设置依赖项的内部标志来解决。¹¹ 

This can be addressed by introducing an internal flag that only allows a client to set the Dependency during initialization.¹¹ 

4.4.4 节中的示例展示了如何处理这些并发症。但在此之前，我们想解释一下何时适合使用属性注入。

The example in section 4.4.4 shows how you can deal with these complications. But before we get to that, we’d like to explain when it’s appropriate to use Property Injection.

4.4.2 何时使用属性注入

4.4.2 When to use Property Injection

仅当您正在开发的类具有良好的Local Default并且您仍然希望使调用者能够提供该类的Dependency的不同实现时，才应使用属性注入。重要的是要注意属性注入最好在依赖项是可选的时候使用。如果需要依赖，构造函数注入总是更好的选择。

Property Injection should only be used when the class you’re developing has a good Local Default, and you still want to enable callers to provide different implementations of the class’s Dependency. It’s important to note that Property Injection is best used when the Dependency is optional. If the Dependency is required, Constructor Injection is always a better pick.

在第 1 章中，我们讨论了编写松散耦合代码的充分理由，从而使模块彼此隔离。但是松散耦合也可以应用于单个模块中的类并取得巨大成功。这通常是通过在模块中引入抽象并让该模块中的类通过抽象进行通信来实现的，而不是彼此紧密耦合。在模块边界内应用松散耦合的主要原因是打开类以实现可扩展性和易于测试。

In chapter 1, we discussed good reasons for writing code with loose coupling, thus isolating modules from each other. But loose coupling can also be applied to classes within a single module with great success. This is often done by introducing Abstractions within a module and letting classes within that module communicate via Abstractions, instead of being tightly coupled to each other. The main reasons for applying loose coupling within a module boundary is to open classes for extensibility and for ease of testing.

到目前为止，我们还没有向您展示任何属性注入的真实示例，因为这种模式的适用性比较有限，尤其是在应用程序开发的上下文中。表 4.3总结了它的优点和缺点。

We haven’t shown you any real examples of Property Injection so far because the applicability of this pattern is more limited, especially in the context of application development. Table 4.3 summarizes its advantages and disadvantages.

属性注入的主要优点是它很容易理解。当人们决定采用 DI 时，我们经常看到这种模式被用作第一次尝试。

The main advantage of Property Injection is that it’s so easy to understand. We’ve often seen this pattern used as a first attempt when people decide to adopt DI.

然而，外观可能具有欺骗性，而且属性注入充满了困难。以稳健的方式实施它具有挑战性。由于前面讨论的时间耦合问题，客户可能会忘记提供依赖项。此外，如果客户试图在类的生命周期中更改依赖项，会发生什么情况？这可能会导致不一致或意外的行为，因此您可能希望保护自己免受该事件的影响。

Appearances can be deceptive, though, and Property Injection is fraught with difficulties. It’s challenging to implement it in a robust manner. Clients can forget to supply the Dependency because of the previously discussed problem of Temporal Coupling. Additionally, what would happen if a client tries to change the Dependency in the middle of the class’s lifetime? This could lead to inconsistent or unexpected behavior, so you may want to protect yourself against that event.

尽管存在缺点，但在构建可重用库时使用属性注入是有意义的。它允许组件定义合理的默认值，这简化了使用库 API 的工作。

Despite the downsides, it makes sense to use Property Injection when building a reusable library. It allows components to define sensible defaults, and this simplifies working with a library’s API.

在开发应用程序时，您将类连接到Composition Root中。构造函数注入可防止您忘记提供依赖项。即使在存在Local Default的情况下，也可以将此类实例提供给Composition Root的构造函数。这简化了类并允许组合根控制所有消费者获得的值。这甚至可能是一个空对象实现。

When developing applications, you wire up your classes in your Composition Root. Constructor Injection prevents you from forgetting to supply the Dependency. Even in the case that there’s a Local Default, such instances can be supplied to the constructor by the Composition Root. This simplifies the class and allows the Composition Root to be in control over the value that all consumers get. This might even be a Null Object implementation.

良好的本地默认值的存在部分取决于模块的粒度。BCL 作为一个相当大的包裹运送；只要默认值保持在 BCL 范围内，就可以说它也是本地的。在下一节中，我们将简要介绍该主题。

The existence of a good Local Default depends in part on the granularity of modules. The BCL ships as a rather large package; as long as the default stays within the BCL, it could be argued that it’s also local. In the next section, we’ll briefly touch on that subject.

4.4.3属性注入的已知用途

4.4.3 Known uses of Property Injection

在 .NET BCL 中，Property Injection比Constructor Injection更常见一些，可能是因为在很多地方定义了良好的Local Defaults，也因为这简化了大多数类的默认实例化。例如，System.ComponentModel.IComponent具有可写Site属性允许您定义一个ISite实例。这主要用于设计时场景（例如，通过 Visual Studio）以在设计器中托管组件时更改或增强组件。以该 BCL 示例作为开胃菜，让我们继续使用和实现Property Injection的更实质性示例。

In the .NET BCL, Property Injection is a bit more common than Constructor Injection, probably because good Local Defaults are defined in many places, and also because this simplifies the default instantiation of most classes. For example, System.ComponentModel.IComponent has a writable Site property that allows you to define an ISite instance. This is mostly used in design time scenarios (for example, by Visual Studio) to alter or enhance a component when it’s hosted in a designer. With that BCL example as an appetizer, let’s move on to a more substantial example of using and implementing Property Injection.

4.4.4 示例：属性注入作为可重用库的扩展模型

4.4.4 Example: Property Injection as an extensibility model of a reusable library

本章前面的示例扩展了上一章的示例应用程序。尽管我们可以使用示例应用程序向您展示属性注入的示例，但这会产生误导，因为在构建应用程序时属性注入几乎不适合；构造函数注入几乎总是更好的选择。相反，我们想向您展示一个可重用库的示例。在这种情况下，我们正在查看来自 Simple Injector 的一些代码。

Earlier examples in this chapter extended the sample application of the previous chapter. Although we could show you an example of Property Injection using the sample application, this would be misleading because Property Injection is hardly ever a good fit when building applications; Constructor Injection is almost always a better choice. Instead, we’d like to show you an example of a reusable library. In this case, we’re looking at some code from Simple Injector.

Simple Injector 是第 4 部分中讨论的DI 容器之一。它可以帮助您构建应用程序的对象图。第 14 章将对 Simple Injector 进行广泛的讨论，因此我们不会在这里详细介绍它。从Property Injection的角度来看，Simple Injector 如何工作并不重要。

Simple Injector is one of the DI Containers that’s discussed in part 4. It helps you construct your application’s object graphs. Chapter 14 will have an extensive discussion on Simple Injector, so we won’t go into much detail about it here. From the perspective of Property Injection, how Simple Injector works isn’t important.

作为一个可重用的库，Simple Injector 广泛使用了Property Injection。它的很多行为都可以扩展，实现的方法是提供其行为的默认实现。Simple Injector 公开允许用户更改默认实现的属性。Simple Injector 允许替换的行为之一是库如何选择正确的构造函数来执行Constructor Injection。¹⁴ 

As a reusable library, Simple Injector makes extensive use of Property Injection. Lots of its behavior can be extended, and the way this is done is by providing default implementations of its behavior. Simple Injector exposes properties that allow the user to change the default implementation. One of the behaviors that Simple Injector allows to be replaced is how the library selects the correct constructor for doing Constructor Injection.¹⁴ 

正如我们在 4.2 节中讨论的那样，您的类应该只有一个构造函数。因此，默认情况下，Simple Injector 只允许创建只有一个公共构造函数的类。在任何其他情况下，Simple Injector 都会抛出异常。然而，简单的注射器，让您覆盖此行为。这可能对某些狭窄的集成场景有用。为此，Simple Injector 定义了一个IConstructorResolutionBehavior接口. ¹⁵  自定义实现可以由用户定义，库提供的默认实现可以通过设置ConstructorResolutionBehavior属性来替换，如下所示：

As we discussed in section 4.2, your classes should only have one constructor. Because of this, Simple Injector, by default, only allows classes that have just one public constructor to be created. In any other case, Simple Injector throws an exception. Simple Injector, however, lets you override this behavior. This might be useful for certain narrow integration scenarios. For this, Simple Injector defines an IConstructorResolutionBehavior interface.¹⁵  A custom implementation can be defined by the user, and the library-provided default can be replaced by setting the ConstructorResolutionBehavior property, as shown here:

var container = new Container();

container.Options.ConstructorResolutionBehavior =
    new CustomConstructorResolutionBehavior();

这Container是 Simple Injector API 中的中心 Facade ¹⁶  模式。它用于指定抽象和实现之间的关系，并构建这些实现的对象图。该类包含一个Options属性的类型。它包括许多允许更改库的默认行为的属性和方法。这些属性之一是. 这是该课程的简化版本ContainerOptionsConstructorResolutionBehaviorContainerOptions及其ConstructorResolutionBehavior财产:

The Container is the central Facade¹⁶  pattern in Simple Injector’s API. It’s used to specify the relationships between Abstractions and implementations, and to build object graphs of these implementations. The class includes an Options property of type ContainerOptions. It includes a number of properties and methods that allow the default behavior of the library to be changed. One of those properties is ConstructorResolutionBehavior. Here’s a simplified version of the ContainerOptions class with its ConstructorResolutionBehavior property:

public class ContainerOptions
{
    IConstructorResolutionBehavior resolutionBehavior =
        new DefaultConstructorResolutionBehavior();    ①  

    public IConstructorResolutionBehavior ConstructorResolutionBehavior
    {
        get
        {
            return this.resolutionBehavior;
        }
        set
        {
            if (value == null)    ②  
              throw new ArgumentNullException("value");

            if (this.Container.HasRegistrations)    ③  
            {
                throw new InvalidOperationException(
                    "The ConstructorResolutionBehav" +
                    "ior property cannot be changed" +
                    " after the first registration " +
                    "has been made to the container.";
            }

            this.resolutionBehavior = value;    ④  
        }
    }
}

该ConstructorResolutionBehavior物业只要容器中没有注册，就可以多次更改。这很重要，因为在进行注册时，Simple Injector 使用指定的ConstructorResolutionBehavior通过分析类的构造函数来验证它是否能够构造这样的类型。如果用户能够在注册后更改构造函数解析行为，则可能会影响早期注册的正确性。这是因为 Simple Injector 最终可能会使用与它在注册时批准正确的组件不同的构造函数。这意味着要么重新评估所有以前的注册，要么阻止用户在注册后更改行为。因为重新评估可能有隐藏的性能成本并且更难实现，所以 Simple Injector 实现了后一种方法。

The ConstructorResolutionBehavior property can be changed multiple times as long as there are no registrations made in the container. This is important, because when registrations are made, Simple Injector uses the specified ConstructorResolutionBehavior to verify whether it’ll be able to construct such a type by analyzing a class’s constructor. If a user was able to change the constructor resolution behavior after registrations were made, it could impact the correctness of earlier registrations. This is because Simple Injector could, otherwise, end up using a different constructor for a component from that which it approved to be correct during the time of registration. This means that either all previous registrations should be reevaluated or the user should be prevented from being able to change the behavior after registrations are made. Because reevaluating can have hidden performance costs and is harder to implement, Simple Injector implements the latter approach.

与Constructor Injection相比，Property Injection涉及更多。它的原始形式可能看起来很简单（如清单 4.19 所示），但是如果实现得当，它往往会更加复杂。

Compared to Constructor Injection, Property Injection is more involved. It may look simple in its raw form (as shown in listing 4.19), but, properly implemented, it tends to be more complex.

您在可重用库中使用Property Injection ，其中Dependency是可选的，并且您有一个很好的Local Default。在存在需要Dependency的短期对象的情况下，您应该使用Method Injection。在其他情况下，您应该使用Constructor Injection。

You use Property Injection in a reusable library where the Dependency is optional and you have a good Local Default. In cases where there’s a short-lived object that requires the Dependency, you should use Method Injection. In other cases, you should use Constructor Injection.

这完成了本章的最后一个模式。以下部分提供了一个简短的回顾，并解释了如何为您的工作选择正确的模式。

This completes the last pattern in this chapter. The following section provides a short recap and explains how to select the right pattern for your job.

4.5 选择要使用的模式

4.5 Choosing which pattern to use

本章介绍的模式是 DI 的核心部分。有了Composition Root和适当的注入模式组合，您就可以实现Pure DI或使用DI Container。应用 DI 时，有许多细微差别和更精细的细节需要学习，但这些模式涵盖了回答“如何注入我的依赖项？”这个问题的核心机制。

The patterns presented in this chapter are a central part of DI. Armed with a Composition Root and an appropriate mix of injection patterns, you can implement Pure DI or use a DI Container. When applying DI, there are many nuances and finer details to learn, but these patterns cover the core mechanics that answer the question, “How do I inject my Dependencies?”

这些模式不可互换。在大多数情况下，您的默认选择应该是Constructor Injection，但在某些情况下，其他模式之一可以提供更好的选择。图 4.9显示了一个决策过程，可以帮助您决定合适的模式，但是，如果有疑问，请选择Constructor Injection。你的选择不会错得离谱。

These patterns aren’t interchangeable. In most cases, your default choice should be Constructor Injection, but there are situations where one of the other patterns affords a better alternative. Figure 4.9 shows a decision process that can help you decide on a proper pattern, but, if in doubt, choose Constructor Injection. You can’t go terribly wrong with that choice.

首先要检查的是依赖项是您需要的东西还是您已经拥有但想与其他合作者交流的东西。在大多数情况下，您可能需要Dependency。但在加载项方案中，您可能希望将当前上下文传达给加载项。每当依赖性因操作而异时，方法注入都是一个很好的实现候选者。

The first thing to examine is whether the Dependency is something you need or something you already have but want to communicate to another collaborator. In most cases, you’ll probably need the Dependency. But in add-in scenarios, you may want to convey the current context to an add-in. Every time the Dependency varies from operation to operation, Method Injection is a good candidate for an implementation.

其次，您需要知道什么样的类需要Dependency。如果您将运行时数据与同一个类中的行为混合在一起，就像您在域Entities中所做的那样，方法注入是一个很好的选择。在其他情况下，当您编写应用程序代码时，与编写可重用库相反，构造函数注入会自动应用。

Secondly, you’ll need to know what kind of class needs the Dependency. In case you’re mixing runtime data with behavior in the same class, as you might do in your domain Entities, Method Injection is a good fit. In other cases, when you’re writing application code, opposed to writing a reusable library, Constructor Injection automatically applies.

在编写应用程序代码时，甚至应该避免使用Local Defaults ，而是将这些默认值设置在应用程序的一个中心位置—— Composition Root。另一方面，在编写可重用库时，本地默认值是决定性因素，因为它可以显式分配依赖项可选——如果未指定覆盖实现，默认值将接管。这种场景可以通过Property Injection有效地实现。

When it comes to writing application code, even the use of Local Defaults should be prevented in favor of having these defaults set in one central place in the application — the Composition Root. On the other hand, when writing a reusable library, a Local Default is the deciding factor, as it can make explicitly assigning the Dependency optional — the default takes over if no overriding implementation is specified. This scenario can be effectively implemented with Property Injection.

构造函数注入应该是 DI 的默认选择。与任何其他 DI 模式相比，它易于理解且更易于稳健地实现。您可以单独使用构造函数注入构建整个应用程序，但了解其他模式可以帮助您在不完全适合的少数情况下做出明智的选择。下一章从相反的方向探讨 DI，并考察使用 DI 的不明智方式。

Constructor Injection should be your default choice for DI. It’s easy to understand and simpler to implement robustly than any of the other DI patterns. You can build entire applications with Constructor Injection alone, but knowing about the other patterns can help you choose wisely in the few cases where it doesn’t fit perfectly. The next chapter approaches DI from the opposite direction and takes a look at ill-advised ways of using DI.

概括

Summary

• 组合根是应用程序中模块组合在一起的单个逻辑位置。应用程序组件的构造应该集中在应用程序的这个单一区域中。
• The Composition Root is a single, logical location in an application where modules are composed together. The construction of your application’s components should be concentrated into this single area of your application.
• 只有启动项目才会有Composition Root。
• Only startup projects will have a Composition Root.
• 尽管组合根可以分布在多个类中，但它们应该位于单个模块中。
• Although a Composition Root can be spread out across multiple classes, they should be in a single module.
• Composition Root直接依赖于系统中的所有其他模块。与紧耦合代码相比，应用组合根模式的松耦合代码降低了模块、子系统和层之间的依赖性总数。
• The Composition Root takes a direct dependency on all other modules in the system. Loosely coupled code that applies the Composition Root pattern lowers the overall number of dependencies between modules, subsystems, and layers, compared to tightly coupled code.
• 即使您可能将合成根放置在与 UI 或表示层相同的程序集中，合成根也不是这些层的一部分。程序集是部署工件，而层是逻辑工件。
• Even though you might place the Composition Root in the same assembly as your UI or presentation layer, the Composition Root isn’t part of those layers. Assemblies are deployment artifacts, whereas layers are logical artifacts.
• 在使用DI 容器的地方，它应该只从Composition Root中引用。所有其他模块都应该忽略DI Container的存在。
• Where a DI Container is used, it should only be referenced from the Composition Root. All other modules should be oblivious to the existence of the DI Container.
• 在组合根之外使用DI 容器会导致服务定位器反模式。
• Use of a DI Container outside the Composition Root leads to the Service Locator anti-pattern.
• 使用DI 容器组合大型对象图的性能开销在设计良好的系统中通常不是问题。
• The performance overhead of using a DI Container to compose large object graphs is usually not an issue in a well-designed system.
• Composition Root应该是整个应用程序中唯一知道构造对象图结构的地方。这意味着应用程序代码无法将依赖项传递给与当前操作并行运行的其他线程，因为消费者无法知道这样做是否安全。相反，当分离并发操作时，组合根的工作是为每个并发操作创建一个新的对象图。
• The Composition Root should be the sole place in the entire application that knows about the structure of the constructed object graphs. This means that application code can’t pass on Dependencies to other threads that run parallel to the current operation, because a consumer has no way of knowing whether it’s safe to do so. Instead, when spinning off concurrent operations, it’s the Composition Root’s job to create a new object graph for each concurrent operation.
• 构造函数注入是通过将所需依赖项指定为类构造函数的参数来静态定义所需依赖项列表的行为。
• Constructor Injection is the act of statically defining the list of required Dependencies by specifying them as parameters to the class’s constructor.
• 用于构造函数注入的构造函数应该只应用保护子句并存储接收依赖项。其他逻辑应该保留在构造函数之外。这使得构建对象图变得快速而可靠。
• A constructor that’s used for Constructor Injection should do no more than apply Guard Clauses and store the receiving Dependencies. Other logic should be kept out of the constructor. This makes building object graphs fast and reliable.
• 构造函数注入应该是 DI 的默认选择，因为它是最可靠且最容易正确应用的。
• Constructor Injection should be your default choice for DI, because it’s the most reliable and the easiest to apply correctly.
• 当需要依赖时，构造函数注入非常适合。然而，重要的是要注意Dependencies几乎不应该是可选的。可选依赖项通过空检查使组件复杂化。在Composition Root内部，当没有可用的合理实现时，应该注入 Null Object 实现。
• Constructor Injection is well suited when a Dependency is required. It’s important to note, however, that Dependencies should hardly ever be optional. Optional Dependencies complicate the component with null checks. Inside the Composition Root, a Null Object implementation should instead be injected when there’s no reasonable implementation available.
• 应用程序组件应该只有一个构造函数。重载的构造函数会导致歧义。对于可重用的类库，比如 BCL，拥有多个构造函数通常是有意义的；对于应用程序组件，它没有。
• Application components should only have a single constructor. Overloaded constructors lead to ambiguity. For reusable class libraries, like the BCL, having multiple constructors often makes sense; for application components, it doesn’t.
• 方法注入是在方法调用上传递依赖关系的行为。
• Method Injection is the act of passing Dependencies on method invocations.
• 如果Dependency或Dependency的消费者对于每个操作可能不同，您可以应用Method Injection。这对于需要将某些运行时上下文传递到加载项的公共 API 的加载项场景，或者当以数据为中心的对象需要特定操作的依赖项时（域实体通常就是这种情况），这可能很有用.
• Where either a Dependency or a Dependency’s consumer can differ for each operation, you can apply Method Injection. This can be useful for add-in scenarios where some runtime context needs to be passed along to the add-in’s public API, or when a data-centric object requires a Dependency for a certain operation, as will often be the case with domain Entities.
• 方法注入不适合在组合根内部使用，因为它会导致时间耦合。
• Method Injection is unsuited for use inside the Composition Root because it leads to Temporal Coupling.
• 通过方法注入接受依赖项的方法不应存储该依赖项。这会导致Temporal Coupling、Captive Dependencies或隐藏的副作用。依赖项只能与构造函数注入和属性注入一起存储。
• A method that accepts a Dependency through Method Injection shouldn’t store that Dependency. This leads to Temporal Coupling, Captive Dependencies, or hidden side effects. Dependencies should only be stored with Constructor Injection and Property Injection.
• 本地默认是源自同一模块或层的依赖项的默认实现。
• A Local Default is a default implementation of a Dependency that originates in the same module or layer.
• 属性注入允许类库为扩展而开放，因为它允许调用者改变库的默认行为。
• Property Injection allows class libraries to be open for extension, because it lets callers change the library’s default behavior.
• Property Injection可能看起来很简单，但如果正确实施，它往往比Constructor Injection更复杂。
• Property Injection may look simple, but when properly implemented, it tends to be more complex compared to Constructor Injection.
• 除了可重用库中的可选依赖项之外，属性注入的适用性是有限的，而构造函数注入通常更合适。Constructor Injection简化了类，允许Composition Root控制所有消费者获得的值，并防止Temporal Coupling。
• Beyond optional Dependencies within reusable libraries, the applicability of Property Injection is limited, and Constructor Injection is usually a better fit. Constructor Injection simplifies the class, allows the Composition Root to be in control over the value that all consumers get, and prevents Temporal Coupling.

在这一章当中

In this chapter

• 使用Control Freak创建紧密耦合的代码
• Creating tightly coupled code with Control Freak
• 使用服务定位器请求类的依赖项
• Requesting a class’s Dependencies with a Service Locator
• 使用Ambient Context使Volatile Dependency全局可用
• Making a Volatile Dependency globally available with Ambient Context
• 使用Constrained Construction强制特定的构造函数签名
• Forcing a particular constructor signature with Constrained Construction

许多菜肴需要用油在平底锅中烹制。如果您对手头的食谱没有经验，您可以开始加热油，然后转身阅读食谱。但是一旦你切完蔬菜，油就会冒烟。您可能认为冒烟的油意味着锅很热，可以做饭了。这是没有经验的厨师的常见误解。当油开始冒烟时，它们也开始分解。这被称为他们的烟点。大多数油在加热超过烟点后不仅味道难闻，而且会形成有害化合物并失去有益的抗氧化剂。

Many dishes require food to be cooked in a pan with oil. If you’re not experienced with the recipe at hand, you might start heating the oil, and then turn your back to read the recipe. But once you’re done cutting the vegetables, the oil is smoking. You might think that the smoking oil means the pan is hot and ready for cooking. This is a common misconception with inexperienced cooks. When oils start to smoke, they also start to break down. This is called their smoke point. Not only do most oils taste awful once heated past their smoke point, they form harmful compounds and lose beneficial antioxidants.

在上一章中，我们简要地将设计模式与食谱进行了比较。模式提供了一种通用语言，我们可以使用它来简洁地讨论一个复杂的概念。当概念（或者更确切地说，实现）变得扭曲时，我们手上就有了一个反模式。

In the previous chapter, we briefly compared design patterns to recipes. A pattern provides a common language we can use to succinctly discuss a complex concept. When the concept (or rather, the implementation) becomes warped, we have an anti-pattern on our hands.

加热油超过其烟点是可视为烹饪反模式的典型示例。这是一个经常发生的错误。许多没有经验的厨师这样做是因为这似乎是一件合理的事情，但失去味道和不健康的食物都是负面后果。

Heating oil past its smoke point is a typical example of what can be considered to be a cooking anti-pattern. It’s a commonly occurring mistake. Many inexperienced cooks do this because it seems a reasonable thing to do, but loss of taste and unhealthful foods are negative consequences.

反模式或多或少是一种描述人们一再犯下的常见错误的形式化方式。在本章中，我们将描述一些与 DI 相关的常见反模式。在我们的职业生涯中，我们看到所有这些都以一种或其他形式使用，我们一直为自己应用所有这些而感到内疚。

Anti-patterns are, more or less, a formalized way of describing common mistakes that people make again and again. In this chapter, we’ll describe some common anti-patterns related to DI. During our career, we’ve seen all of them in use in one form or other, and we’ve been guilty of applying all of them ourselves.

在许多情况下，反模式代表了在应用程序中实现 DI 的真诚尝试。但由于不完全符合 DI 基础，这些实现可能会演变成弊大于利的解决方案。了解这些反模式可以让您了解在尝试第一个 DI 项目时需要注意哪些陷阱。但即使您多年来一直在应用 DI，仍然很容易出错。

In many cases, anti-patterns represent sincere attempts at implementing DI in an application. But because of not fully complying with DI fundamentals, the implementations can morph into solutions that do more harm than good. Learning about these anti-patterns can give you an idea about what traps to be aware of as you venture into your first DI projects. But even if you’ve been applying DI for years, it’s still easy to make mistakes.

可以通过将代码重构为第 4 章介绍的一种 DI 模式来修复反模式。修复每次出现的具体困难程度取决于实现的细节。对于每个反模式，我们将提供一些关于如何将其重构为更好模式的通用指导。

Anti-patterns can be fixed by refactoring the code toward one of the DI patterns introduced in chapter 4. Exactly how difficult it is to fix each occurrence depends on the details of the implementation. For each anti-pattern, we’ll supply some generalized guidance on how to refactor it toward a better pattern.

遗留代码有时需要采取严厉措施才能使您的代码可测试。这通常意味着采取小步骤来防止意外破坏以前工作的应用。在某些情况下，反模式可能是最合适的临时解决方案。尽管反模式的应用可能是对原始代码的改进，但重要的是要注意，这并不会使它成为反模式。存在其他记录在案且可重复的解决方案，这些解决方案被证明更有效。本章涵盖的反模式列于表 5.1中。

Legacy code sometimes requires drastic measures to make your code Testable. This often means taking small steps to prevent accidentally breaking a previously working application. In some cases, an anti-pattern might be the most appropriate temporary solution. Even though the application of an anti-pattern might be an improvement over the original code, it’s important to note that this doesn’t make it any less an anti-pattern; other documented and repeatable solutions exist that are proven to be more effective. The anti-patterns covered in this chapter are listed in table 5.1.

本章的其余部分将更详细地描述每个反模式，并按重要性排序。您可以从头到尾阅读，也可以只阅读您感兴趣的部分——每个部分都有一个独立的部分。如果您决定只阅读本章的一部分，我们建议您阅读Control Freak和Service Locator。

The rest of this chapter describes each anti-pattern in greater detail, presenting them in order of importance. You can read from start to finish or only read the ones you’re interested in — each has a self-contained section. If you decide to read only part of this chapter, we recommend that you read Control Freak and Service Locator.

正如构造函数注入是最重要的 DI 模式一样，Control Freak是最常出现的反模式。它有效地阻止您应用任何类型的适当的 DI，所以我们需要在我们之前关注这个反模式向其他人讲话——你也应该如此。但是因为Service Locator看起来像是在解决一个问题，所以它是最危险的。我们将在 5.2 节中解决这个问题。

Just as Constructor Injection is the most important DI pattern, Control Freak is the most frequently occurring of the anti-patterns. It effectively prevents you from applying any kind of proper DI, so we’ll need to focus on this anti-pattern before we address the others — and so should you. But because Service Locator looks like it’s solving a problem, it’s the most dangerous. We’ll address that in section 5.2.

5.1 控制狂

5.1 Control Freak

控制反转的反义词是什么？控制反转一词最初是为了识别与正常情况相反的事物而创造的，但我们不能谈论“一切照旧”反模式。相反，Control Freak描述了一个不会放弃对其Volatile Dependencies的控制的类.

What’s the opposite of Inversion of Control? Originally the term Inversion of Control was coined to identify the opposite of the normal state of affairs, but we can’t talk about the “Business as Usual” anti-pattern. Instead, Control Freak describes a class that won’t relinquish control of its Volatile Dependencies.

例如，当您使用关键字创建Volatile Dependency的新实例时，就会出现Control Freak反模式。以下清单演示了Control Freak反模式的实现。new

As an example, the Control Freak anti-pattern happens when you create a new instance of a Volatile Dependency by using the new keyword. The following listing demonstrates an implementation of the Control Freak anti-pattern.

清单 5.1 一个Control Freak反模式示例

Listing 5.1 A Control Freak anti-pattern example

public class HomeController : Controller
{
    public ViewResult Index()
    {
        var service = new ProductService();    ①  

        var products = service.GetFeaturedProducts();
        return this.View(products);
    }
}

每次创建Volatile Dependency时，您都明确声明您将控制实例的生命周期，并且没有其他人有机会拦截该特定对象。虽然new关键字对于Volatile Dependencies来说是一种代码味道，您无需担心将其用于Stable Dependencies。^2个 

Every time you create a Volatile Dependency, you explicitly state that you’re going to control the lifetime of the instance and that no one else will get a chance to Intercept that particular object. Although the new keyword is a code smell when it comes to Volatile Dependencies, you don’t need to worry about using it for Stable Dependencies.² 

Control Freak最明显的例子是当你不努力在你的代码中引入抽象时。在第 2 章中，当 Mary 实现她的电子商务应用程序（第 2.1 节）时，您看到了几个这样的例子。这样的做法不尝试引入 DI。但即使在开发人员听说过 DI 和可组合性的地方，也经常可以在某些变体中找到Control Freak反模式。

The most blatant example of Control Freak is when you make no effort to introduce Abstractions in your code. You saw several examples of that in chapter 2 when Mary implemented her e-commerce application (section 2.1). Such an approach makes no attempt to introduce DI. But even where developers have heard about DI and composability, the Control Freak anti-pattern can often be found in some variation.

在接下来的部分中，我们将向您展示一些类似于我们在生产中使用过的代码的示例。在每一种情况下，开发人员都有最好的接口编程意图，但从未理解潜在的力量和动机。

In the next sections, we’ll show you some examples that resemble code we’ve seen used in production. In every case, the developers had the best intentions of programming to interfaces, but never understood the underlying forces and motivations.

5.1.1 例子：通过更新依赖来控制怪胎

5.1.1 Example: Control Freak through newing up Dependencies

许多开发人员听说过接口编程的原理，但不了解其背后更深层次的原理。为了做正确的事或遵循最佳实践，他们编写了没有多大意义的代码。例如，在清单 3.9 中，您看到了一个ProductService使用IProductRepository接口实例的示例检索特色产品列表。作为提醒，以下重复相关代码：

Many developers have heard about the principle of programming to interfaces but don’t understand the deeper rationale behind it. In an attempt to do the right thing or to follow best practices, they write code that doesn’t make much sense. For example, in listing 3.9, you saw an example of a ProductService that uses an instance of the IProductRepository interface to retrieve a list of featured products. As a reminder, the following repeats the relevant code:

public IEnumerable<DiscountedProduct> GetFeaturedProducts()
{
    return
        from product in this.repository.GetFeaturedProducts()
        select product.ApplyDiscountFor(this.userContext);
}

重点是成员变量代表一个Abstraction。在第 3 章中，您看到了如何通过构造函数注入填充字段，但我们已经看到了其他更简单的尝试。下面的清单显示了一种这样的尝试。repositoryrepository

The salient point is that the repository member variable represents an Abstraction. In chapter 3, you saw how the repository field can be populated via Constructor Injection, but we’ve seen other, more naïve attempts. The following listing shows one such attempt.

清单 5.2 新建一个ProductRepository

Listing 5.2 Newing up a ProductRepository

private readonly IProductRepository repository;

public ProductService()
{
    this.repository = new SqlProductRepository();    ①  
}

该repository字段被声明为IProductRepository接口，因此ProductService类中的任何成员（例如）程序到接口。虽然这听起来像是正确的做法，但这样做并没有带来太多好处，因为在运行时，类型将始终是一个. 您无法拦截或更改变量GetFeaturedProductsSqlProductRepositoryrepository除非你更改代码并重新编译。此外，如果您将变量硬编码为始终具有特定的具体类型，那么通过将变量定义为抽象并不会获得太多好处。直接更新依赖关系是Control Freak反模式的一个例子。

The repository field is declared as the IProductRepository interface, so any member in the ProductService class (such as GetFeaturedProducts) programs to an interface. Although this sounds like the right thing to do, not much is gained from doing so because, at runtime, the type will always be a SqlProductRepository. There’s no way you can Intercept or change the repository variable unless you change the code and recompile. Additionally, you don’t gain much by defining a variable as an Abstraction if you hard-code it to always have a specific concrete type. Directly newing up Dependencies is one example of the Control Freak anti-pattern.

在我们开始分析和解决由Control Freak产生的结果问题的可能方法之前，让我们看一些更多的例子，让您更好地了解上下文和常见的失败尝试。在下一个示例中，很明显解决方案不是最优的。大多数开发人员将尝试改进他们的方法。

Before we get to the analysis and possible ways to address the resulting issues generated by a Control Freak, let’s look at some more examples to give you a better idea of the context and common failed attempts. In the next example, it’s apparent that the solution isn’t optimal. Most developers will attempt to refine their approach.

5.1.2 示例：通过工厂控制 Freak

5.1.2 Example: Control Freak through factories

解决新建依赖项中明显问题的最常见和错误的尝试涉及某种工厂。对于工厂，有多种选择。我们将快速介绍以下各项：

The most common and erroneous attempt to fix the evident problems from newing up Dependencies involves a factory of some sort. When it comes to factories, there are several options. We’ll quickly cover each of the following:

• 混凝土厂
• Concrete Factory
• 抽象工厂
• Abstract Factory
• 静态工厂
• Static Factory

如果被告知她只能处理IProductRepository Abstraction，Mary Rowan（来自第 2 章）将介绍一个ProductRepositoryFactory可以生成她需要获取的实例的对象。让我们聆听她与同事 Jens 讨论这种方法的过程。我们预计他们的讨论将方便地涵盖我们列出的工厂选项。

If told that she could only deal with the IProductRepository Abstraction, Mary Rowan (from chapter 2) would introduce a ProductRepositoryFactory that would produce the instances she needs to get. Let’s listen in as she discusses this approach with her colleague Jens. We predict that their discussion will, conveniently, cover the factory options we’ve listed.

玛丽： 我们需要这个类中的一个实例IProductRepositoryProductService. ButIProductRepository是一个接口，所以我们不能只创建它的新实例，我们的顾问说我们不应该创建SqlProductRepository任何一个的新实例。

Mary: We need an instance of IProductRepository in this ProductService class. But IProductRepository is an interface, so we can’t just create new instances of it, and our consultant says that we shouldn’t create new instances of SqlProductRepository either.

Jens： 某种工厂怎么样？

Jens: What about some sort of factory?

玛丽： 是的，我也在想同样的事情，但我不确定如何进行。我不明白它是如何解决我们的问题的。看这里 -

Mary: Yes, I was thinking the same thing, but I’m not sure how to proceed. I don’t understand how it solves our problem. Look here —

Mary 开始编写一些代码来演示她的问题。这是玛丽写的代码：

Mary starts to write some code to demonstrate her problem. This is the code that Mary writes:

public class ProductRepositoryFactory
{
    public IProductRepository Create()
    {
        return new SqlProductRepository();
    }
}

混凝土厂

Concrete Factory

Mary： 这ProductRepositoryFactory封装了关于如何创建ProductRepository实例的知识，但它并没有解决问题，因为我们必须ProductService像这样使用它：

Mary: This ProductRepositoryFactory encapsulates knowledge about how to create ProductRepository instances, but it doesn’t solve the problem, because we’d have to use it in the ProductService like this:

var factory = new ProductRepositoryFactory();
this.repository = factory.Create();

看？现在我们需要在 中创建ProductRepositoryFactory该类的一个新实例ProductService，但这仍然对SqlProductRepository. 我们唯一取得的成就是将问题转移到另一个类中。

See? Now we need to create a new instance of the ProductRepositoryFactory class in the ProductService, but that still hard-codes the use of SqlProductRepository. The only thing we’ve achieved is moving the problem into another class.

Jens：是的，我明白了——我们不能用抽象工厂来解决问题吗？

Jens: Yes, I see — couldn’t we solve the problem with an Abstract Factory instead?

让我们暂停 Mary 和 Jens 的讨论，评估一下发生了什么。Mary 是完全正确的，混凝土工厂类不能解决Control Freak问题，而只能解决它。它在不增加任何价值的情况下使代码更加复杂。ProductService 现在直接控制工厂的生命周期，而工厂直接控制的生命周期ProductRepository，所以你仍然无法在运行时拦截或替换 Repository 实例。

Let’s pause Mary and Jens’ discussion to evaluate what happened. Mary is entirely correct that a Concrete Factory class doesn’t solve the Control Freak issue but only moves it around. It makes the code more complex without adding any value. ProductService now directly controls the lifetime of the factory, and the factory directly controls the lifetime of ProductRepository, so you still can’t Intercept or replace the Repository instance at runtime.

很明显，混凝土工厂不会解决任何 DI 问题，而且我们从未见过它以这种方式成功使用过。Jens 关于抽象工厂的评论听起来更有希望。

It’s fairly evident that a Concrete Factory won’t solve any DI problems, and we’ve never seen it used successfully in this fashion. Jens’ comment about Abstract Factory sounds more promising.

抽象工厂

Abstract Factory

让我们继续 Mary 和 Jens 的讨论，听听 Jens 对抽象工厂的看法。

Let’s resume Mary and Jens’ discussion and hear what Jens has to say about Abstract Factory.

Jens：如果我们像这样抽象工厂会怎么样？

Jens: What if we made the factory abstract, like this?

public interface IProductRepositoryFactory
{
    IProductRepository Create();
}

这意味着我们没有对 的任何引用进行硬编码SqlProductRepository，并且我们可以使用 中的工厂ProductService来获取 的实例IProductRepository。

This means we haven’t hard-coded any references to SqlProductRepository, and we can use the factory in the ProductService to get instances of IProductRepository.

Mary：但是既然工厂是抽象的，我们如何获得它的新实例呢？

Mary: But now that the factory is abstract, how do we get a new instance of it?

Jens：我们可以创建一个返回SqlProductService实例的实现。

Jens: We can create an implementation of it that returns SqlProductService instances.

Mary：是的，但是我们如何创建它的实例呢？

Mary: Yes, but how do we create an instance of that?

Jens：我们刚刚在ProductService……哦。等待 -

Jens: We just new it up in the ProductService ... Oh. Wait —

玛丽：那会让我们回到起点。

Mary: That would put us back where we started.

Mary 和 Jens 很快意识到抽象工厂并不能改变他们的处境。他们最初的难题是他们需要一个 abstract 的实例，而现在他们需要一个 abstract 的实例。IProductRepositoryIProductRepositoryFactory

Mary and Jens quickly realize that an Abstract Factory doesn’t change their situation. Their original conundrum was that they needed an instance of the abstract IProductRepository, and now they need an instance of the abstract IProductRepositoryFactory instead.

既然 Mary 和 Jens 已经拒绝将抽象工厂作为一种可行的选择，那么一个破坏性的选择仍然存在。玛丽和詹斯即将得出结论。

Now that Mary and Jens have rejected the Abstract Factory as a viable option, one damaging option is still open. Mary and Jens are about to reach a conclusion.

静态工厂

Static Factory

让我们听听 Mary 和 Jens 决定他们认为可行的方法。

Let’s listen as Mary and Jens decide on an approach that they think will work.

玛丽：让我们做一个静态工厂。让我演示给你看：

Mary: Let’s make a Static Factory. Let me show you:

public static class ProductRepositoryFactory
{
    public static IProductRepository Create()
    {
        return new SqlProductRepository();
    }
}

既然类是静态的，我们就不需要处理如何创建它了。

Now that the class is static, we don’t need to deal with how to create it.

Jens：但是我们仍然硬编码我们返回SqlProductRepository实例，所以它对我们有任何帮助吗？

Jens: But we’ve still hard-coded that we return SqlProductRepository instances, so does it help us in any way?

Mary：我们可以通过确定ProductRepository要创建哪种类型的配置设置来处理这个问题。像这样：

Mary: We could deal with this via a configuration setting that determines which type of ProductRepository to create. Like this:

public static IProductRepository Create()
{
    IConfigurationRoot configuration = new ConfigurationBuilder()
        .SetBasePath(Directory.GetCurrentDirectory())
        .AddJsonFile("appsettings.json")
        .Build();

    string repositoryType = configuration["productRepository"];

    switch (repositoryType)
    {
        case "sql": return new SqlProductRepository();
        case "azure": return AzureProductRepository();
        default: throw new InvalidOperationException("...");
    }
}

看？这样我们就可以确定我们应该使用基于 SQL Server 的实现还是基于 Microsoft Azure 的实现，我们甚至不需要重新编译应用程序来从一个更改为另一个。

See? This way we can determine whether we should use the SQL Server–based implementation or the Microsoft Azure–based implementation, and we don’t even need to recompile the application to change from one to the other.

詹斯：酷！这就是我们要做的。那个顾问现在一定很高兴吧！

Jens: Cool! That’s what we’ll do. That consultant must be happy now!

有几个原因导致这样的静态工厂不能为接口编程的最初目标提供令人满意的解决方案。看一下图 5.1中的依赖关系图。

There are several reasons why such a Static Factory doesn’t provide a satisfactory solution to the original goal of programming to interfaces. Take a look at the Dependency graph in figure 5.1.

所有类都需要引用抽象如下：IProductRepository

All classes need to reference the abstract IProductRepository as follows:

• ProductService因为它消耗IProductRepository实例
• ProductService because it consumes IProductRepository instances
• ProductRepositoryFactory因为它创建IProductRepository实例
• ProductRepositoryFactory because it creates IProductRepository instances
• AzureProductRepository因为他们实施SqlProductRepositoryIProductRepository
• AzureProductRepository and SqlProductRepository because they implement IProductRepository

ProductRepositoryFactory取决于类和类。因为直接依赖于，所以它也依赖于两个具体实现——回忆一下 4.1.4 节中的依赖是可传递的。AzureProductRepositorySqlProductRepositoryProductServiceProductRepositoryFactoryIProductRepository

ProductRepositoryFactory depends on both the AzureProductRepository and SqlProductRepository classes. Because ProductService directly depends on ProductRepositoryFactory, it also depends on both concrete IProductRepository implementations — recall from section 4.1.4 that dependencies are transitive.

只要ProductService依赖于 static ProductRepositoryFactory，就会遇到无法解决的设计问题。如果您ProductRepositoryFactory在域层中定义静态，则意味着域层需要依赖于数据访问层，因为ProductRepositoryFactory创建了一个SqlProductRepository位于该层中的对象。然而，数据访问层已经依赖于域层，因为它使用了与该层类似的SqlProductRepository类型和抽象。这会导致两个项目之间的循环引用。此外，如果你进入数据访问层，你仍然需要从领域层到数据访问层的依赖，因为依赖于. 这仍然会导致循环依赖。图 5.2ProductIProductRepositoryProductRepositoryFactoryProductServiceProductRepositoryFactory显示此设计问题。

As long as ProductService has a dependency on the static ProductRepositoryFactory, you have unsolvable design issues. If you define the static ProductRepositoryFactory in the domain layer, it means that the domain layer needs to depend on the data access layer, because ProductRepositoryFactory creates a SqlProductRepository that’s located in that layer. The data access layer, however, already depends on the domain layer because SqlProductRepository uses types and Abstractions like Product and IProductRepository from that layer. This causes a circular reference between the two projects. Additionally, if you move ProductRepositoryFactory into the data access layer, you still need a dependency from the domain layer to the data access layer because ProductService depends on ProductRepositoryFactory. This still causes a circular dependency. Figure 5.2 shows this design issue.

无论您如何移动类型，防止这些项目之间循环依赖的唯一方法是为所有类型创建一个项目。然而，这不是一个可行的选择，因为它将域层与数据访问层紧密耦合，并且不允许替换您的数据访问层。

No matter how you move your types around, the only way to prevent these circular dependencies between projects is by creating a single project for all types. This isn’t a viable option, however, because it tightly couples the domain layer to the data access layer and disallows your data access layer from being replaced.

Mary 和 Jens没有松散耦合的IProductRepository实现，而是以紧密耦合的模块结束。更糟糕的是，工厂总是拖延所有的实现——即使是那些不需要的！如果他们托管在 Azure 上，他们仍然需要将 Commerce.SqlDataAccess.dll（例如）与他们的应用程序一起分发。

Instead of loosely coupled IProductRepository implementations, Mary and Jens end up with tightly coupled modules. Even worse, the factory always drags along all implementations — even those that aren’t needed! If they host on Azure, they still need to distribute Commerce.SqlDataAccess.dll (for example) with their application.

如果 Mary 和 Jens 需要第三种类型的IProductRepository，他们将不得不更改工厂并重新编译他们的解决方案。尽管他们的解决方案可能是可配置的，但它是不可扩展的；如果一个单独的团队，甚至公司，需要创建一个新的存储库，他们将无法访问源代码。IProductRepository用特定于测试的实现替换具体实现也是不可能的，因为这需要IProductRepository在运行时定义实例，而不是在设计时静态地在配置文件中定义。

If Mary and Jens ever need a third type of IProductRepository, they’ll have to change the factory and recompile their solution. Although their solution may be configurable, it isn’t extensible; if a separate team, or even company, needs to create a new Repository, they’ll have no options without access to the source code. It’s also impossible to replace the concrete IProductRepository implementations with test-specific implementations, because that requires defining the IProductRepository instance at runtime, instead of statically in a configuration file at design time.

简而言之，静态工厂似乎可以解决问题，但实际上只会使问题复杂化。即使在最好的情况下，它也会迫使您引用Volatile Dependencies。当重载构造函数与Foreign Defaults结合使用时，可以看到这种反模式的另一种变体，正如您将在下一个示例中看到的那样。

In short, a Static Factory may seem to solve the problem but, in reality, only compounds it. Even in the best cases, it forces you to reference Volatile Dependencies. Another variation of this anti-pattern can be seen when overloaded constructors are used in combination with Foreign Defaults, as you’ll see in the next example.

5.1.3 示例：通过重载构造函数控制 Freak

5.1.3 Example: Control Freak through overloaded constructors

构造函数重载在许多 .NET 代码库（包括 BCL）中相当普遍。通常，许多重载为一两个成熟的构造函数提供合理的默认值，这些构造函数将所有相关参数作为输入。（这种做法称为构造函数链接.) 有时，我们会看到 DI 的其他用途。

Constructor overloads are fairly common in many .NET code bases (including the BCL). Often, the many overloads provide reasonable defaults to one or two full-blown constructors that take all relevant parameters as input. (This practice is called Constructor Chaining.) At times, we see other uses when it comes to DI.

一个非常常见的反模式定义了一个特定于测试的构造函数重载，允许您显式定义Dependency，尽管生产代码使用无参数构造函数。当Dependency的默认实现代表Foreign Default而不是Local Default时，这可能是有害的。正如我们在 4.4.2 节中解释的那样，您通常希望使用构造函数注入来提供所有易失性依赖项——即使是那些可能是本地默认值的依赖项。

An all-too-common anti-pattern defines a test-specific constructor overload that allows you to explicitly define a Dependency, although the production code uses a parameterless constructor. This can be detrimental when the default implementation of the Dependency represents a Foreign Default rather than a Local Default. As we explained in section 4.4.2, you typically want to supply all Volatile Dependencies using Constructor Injection — even those that could be a Local Default.

以下清单显示了ProductService具有默认构造函数和重载构造函数的类。这是不该做什么的一个例子。

The following listing shows the ProductService class with a default and an overloaded constructor. It’s an example of what not to do.

ProductService具有多个构造函数的清单 5.3

Listing 5.3 ProductService with multiple constructors

private readonly IProductRepository repository;

public ProductService()    ①  
    : this(new SqlProductRepository())    ①  
{    ①  
}    ①  

public ProductService(IProductRepository repository)    ②  
{    ②  
    if (repository == null)    ②  
        throw new ArgumentNullException("repository");    ②  
    ②  
    this.repository = repository;    ②  
}    ②  

乍一看，这种编码风格似乎是两全其美。为了进行单元测试，它允许提供虚假的依赖项；然而，仍然可以方便地创建该类，而无需提供其Dependencies。下面的例子展示了这种风格：

At first sight, this coding style might seem like the best of both worlds. It allows fake Dependencies to be supplied for the sake of unit testing; whereas, the class can still be conveniently created without having to supply its Dependencies. The following example shows this style:

var productService = new ProductService();

通过让ProductService创建SqlProductRepository Volatile Dependency，您再次强制模块之间的强耦合。尽管ProductService可以在不同IProductRepository的实现中重复使用，但通过在测试时通过最灵活的构造函数重载提供它们，它会禁用拦截应用程序中IProductRepository实例的能力。

By letting ProductService create the SqlProductRepository Volatile Dependency, you again force strong coupling between modules. Although ProductService can be reused with different IProductRepository implementations, by supplying them via the most flexible constructor overload while testing, it disables the ability to Intercept the IProductRepository instance in the application.

既然您已经看到了Control Freak的一些示例，我们希望您对要查找的内容有更好的了解——new关键字的出现次数在易失性依赖项旁边。这可以使您避免最明显的陷阱。但是，如果您需要从这种反模式的现有事件中解脱出来，下一节将帮助您处理此类任务。

Now that you’ve seen a few of examples of Control Freak, we hope you have a better idea what to look for — occurrences of the new keyword next to Volatile Dependencies. This may enable you to avoid the most obvious traps. But if you need to untangle yourself from an existing occurrence of this anti-pattern, the next section will help you deal with such a task.

5.1.4控制狂分析

5.1.4 Analysis of Control Freak

Control Freak是Inversion of Control的对立面。当您直接控制Volatile Dependencies的创建时，您最终会得到紧密耦合的代码，而失去了第 1 章中概述的许多（如果不是全部）松散耦合的好处。

Control Freak is the antithesis of Inversion of Control. When you directly control the creation of Volatile Dependencies, you end up with tightly coupled code, missing many (if not all) of the benefits of loose coupling outlined in chapter 1.

Control Freak是最常见的 DI 反模式。它代表了大多数编程语言中创建实例的默认方式，因此即使在开发人员从未考虑过 DI 的应用程序中也可以观察到它。这是一种创建新对象的自然而根深蒂固的方式，许多开发人员发现很难放弃。即使当他们开始考虑 DI 时，他们也很难动摇他们必须以某种方式控制创建实例的时间和地点的心态。放开这种控制可能是一个艰难的精神飞跃；但是，即使您做到了，也有其他的陷阱需要避免，尽管这些陷阱较小。

Control Freak is the most common DI anti-pattern. It represents the default way of creating instances in most programming languages, so it can be observed even in applications where developers have never considered DI. It’s such a natural and deeply rooted way to create new objects that many developers find it difficult to discard. Even when they begin to think about DI, they have a hard time shaking the mindset that they must somehow control when and where instances are created. Letting go of that control can be a difficult mental leap to make; but, even if you make it, there are other, although lesser, pitfalls to avoid.

Control Freak反模式的负面影响

The negative effects of the Control Freak anti-pattern

由于Control Freak导致的紧密耦合代码，模块化设计的许多好处可能会丧失。这些在前面的每一节中都有介绍，但总结一下：

With the tightly coupled code that’s the result of Control Freak, many benefits of modular design are potentially lost. These were covered in each of the previous sections, but to summarize:

• 尽管您可以将应用程序配置为使用多个预配置的Dependencies之一，但您不能随意替换它们。不可能提供在应用程序编译后创建的实现，当然也不可能提供特定实例作为实现。
• Although you can configure an application to use one of multiple preconfigured Dependencies, you can’t replace them at will. It isn’t possible to provide an implementation that was created after the application was compiled, and it certainly isn’t possible to provide specific instances as an implementation.
• 重用使用模块变得更加困难，因为它拖拽了在新上下文中可能不需要的依赖项。例如，考虑一个模块，该模块通过使用Foreign Default依赖于 ASP.NET Core 库。这使得将该模块重用为不应或不能依赖 ASP.NET Core 的应用程序（例如，Windows 服务或手机应用程序）的一部分变得更加困难。
• It becomes harder to reuse the consuming module because it drags with it Dependencies that may be undesirable in the new context. As an example of this, consider a module that, through the use of a Foreign Default, depends on ASP.NET Core libraries. This makes it harder to reuse that module as part of an application that should’t or can’t depend on ASP.NET Core (for example, a Windows Service or mobile phone application).
• 这使得并行开发更加困难。这是因为消费应用程序与其Dependencies的所有实现紧密耦合。
• It makes parallel development more difficult. This is because the consuming application is tightly coupled to all implementations of its Dependencies.
• 可测试性受到影响。Test Doubles 不能用作Dependency的替代品。
• Testability suffers. Test Doubles can’t be used as substitutes for the Dependency.

通过仔细的设计，您仍然可以实现具有明确定义的职责的紧密耦合的应用程序，这样可维护性就不会受到影响。但即便如此，成本也太高了，而且你会保留很多限制。考虑到实现这一目标所需的工作量，没有理由继续投资于Control Freak。您需要远离Control Freak并转向适当的 DI。

With careful design, you can still implement tightly coupled applications with clearly defined responsibilities so that maintainability doesn’t suffer. But even so, the cost is too high, and you’ll retain many limitations. Given the amount of effort required to accomplish that, there’s no reason to continue investing in Control Freak. You need to move away from Control Freak and toward proper DI.

从Control Freak重构到 DI

Refactoring from Control Freak toward DI

要摆脱Control Freak，您需要将代码重构为第 4 章中介绍的正确 DI 设计模式之一。作为初始步骤，您应该使用图 4.9 中给出的指导来确定目标模式。在大多数情况下，这将是构造函数注入。重构步骤如下：

To get rid of Control Freak, you need to refactor your code toward one of the proper DI design patterns presented in chapter 4. As an initial step, you should use the guidance given in figure 4.9 to determine which pattern to aim for. In most cases, this will be Constructor Injection. The refactoring steps are as follows:

1. 确保您正在编程为Abstraction。在示例中，情况已经如此；但在其他情况下，您可能需要先提取接口并更改变量声明。
1. Ensure that you’re programming to an Abstraction. In the examples, this was already the case; but in other situations, you may need to first extract an interface and change variable declarations.
2. 如果您在多个地方创建依赖项的特定实现，请将它们全部移动到一个创建方法中。确保此方法的返回值表示为抽象而不是具体类型。
2. If you create a particular implementation of a Dependency in multiple places, move them all to a single creation method. Make sure this method’s return value is expressed as the Abstraction and not the concrete type.
3. 现在您只有一个地方可以创建实例，通过实现其中一种 DI 模式（例如构造函数注入）将此创建移出使用类。
3. Now that you have only a single place where you create the instance, move this creation out of the consuming class by implementing one of the DI patterns, such as Constructor Injection.

ProductService对于前面几节中的示例，构造函数注入是一个很好的解决方案。

In the case of the ProductService examples in the previous sections, Constructor Injection is an excellent solution.

清单 5.4使用构造函数注入 重构Control Freak

Listing 5.4 Refactoring away from Control Freak using Constructor Injection

public class ProductService : IProductService
{
    private readonly IProductRepository repository;

    public ProductService(IProductRepository repository)
    {
        if (repository == null)
            throw new ArgumentNullException("repository");

        this.repository = repository;
    }
}

Control Freak是迄今为止最具破坏性的反模式，但即使您控制了它，也会出现更微妙的问题。下一节将介绍更多反模式。尽管它们比Control Freak问题更少，但它们也往往更容易解决，因此请多加留意，并在发现它们时进行修复。